Many beginners in embedded systems, upon seeing that Linux can run graphical interfaces, connect to networks, and execute complex programs, believe that this is what “high-end players” should learn. They dismiss MCUs, which can only control a few lights and sensors, as unworthy of attention. But did you know? The underlying logic of Linux is fundamentally based on what MCUs have already established.
Jumping straight from the 51 microcontroller to STM32 without even understanding GPIO configuration, and rushing to burn a Linux image, what happens? Faced with the pinout diagram in the development board manual, you can’t even tell which pin corresponds to which function, let alone understand the device tree in Linux. Later, while following a tutorial to write a driver program, even though I copied the code verbatim, I encountered a compilation error stating “device node does not exist”. I stared at the error message in the terminal for an entire afternoon, unable to figure out where the problem lay.
It wasn’t until I dedicated three months to studying MCUs that I suddenly realized: the “drivers” in Linux are essentially “manuals” for hardware, and the foundation of this “manual” is the register configuration within the MCU; the “interrupts” in Linux are identical to the external interrupt logic in the 51 microcontroller, just with a few layers of encapsulation added; even the process scheduling in Linux has its underlying principles reflected in RTOS task scheduling. It’s like wanting to learn to drive a car but skipping the bicycle stage. If you don’t even know how to steer or brake, sitting in a car will only leave you spinning in place, and you’ll be flustered in slightly more complex traffic conditions.
MCU+RTOS is the “bicycle” of embedded systems; only by solidifying these fundamentals can you confidently handle the “car” that is Linux. There’s a saying in embedded development: “30% coding, 70% debugging”. The ability to debug is almost entirely developed during the MCU phase. If you skip this stage, you’ll be like a headless fly, bumping around when problems arise.
I remember the first time I used a Linux development board for a project to implement a temperature and humidity sensor data collection function. After connecting the hardware according to the tutorial and burning the program, the terminal kept displaying “data read failed”. My mind went blank: was the sensor broken? Did the driver fail to load? Was there an issue with the I2C bus? Or were the pins connected incorrectly? I scoured forum posts and tried various methods: recompiling the driver, replacing the sensor, checking the wiring, but the problem remained unsolved. Finally, an experienced engineer came over and found the issue in just three minutes. It turned out I had reversed the SDA and SCL pins of the sensor. He smiled and said, “Haven’t you worked with MCUs before? This kind of problem can be spotted at a glance with an oscilloscope measuring the pin levels.” That day I realized that those who have worked with MCUs approach debugging with a “map” and a “compass”, knowing where to start troubleshooting; while those who haven’t worked with MCUs can only wander aimlessly in the “fog”. During the MCU phase, you will encounter various “quirky” problems: if the LED chaser doesn’t light up, it might be due to incorrect IO mode configuration; if there’s no data on the serial port, it could be a baud rate mismatch; if the timer doesn’t trigger, it might be due to incorrect interrupt priority settings.
These problems, while simple, enhance your debugging skills with each resolution. You will learn to use a multimeter to measure voltage, an oscilloscope to observe waveforms, and to print debug information via the serial port. These “fundamentals” are equally applicable in Linux development. For instance, when debugging drivers in Linux, you need to know how to check device nodes, how to view interrupt statuses, and how to print kernel logs; the logic behind these operations is akin to checking register values, viewing interrupt flags, and printing information via the serial port in MCUs. If you haven’t even grasped debugging in MCUs, facing more complex issues in Linux will leave you helpless. The competition in the embedded industry is becoming increasingly fierce, and the standards for hiring are rising. Especially for entry-level embedded engineer positions, almost all require “familiarity with MCU development, understanding of RTOS, and mastery of Linux fundamentals”. If you skip MCU+RTOS and jump straight to Linux, your resume may not even pass HR’s screening.
I have a friend who focused solely on learning Linux in college, claiming on his resume to be “proficient in Linux application development and familiar with kernel drivers”. However, during the interview, he was left speechless when asked, “How would you implement PWM output using an STM32 microcontroller?” He stammered and couldn’t answer; the interviewer then asked, “What is the difference between semaphores and mutexes in RTOS?” He still couldn’t respond.
In the end, the interviewer shook his head and said, “You haven’t even mastered the basics; how can you excel in Linux development?” The reason companies value a foundation in MCUs and RTOS is that embedded development requires “full-stack thinking”. Many positions require both upper-layer application development in Linux and lower-layer driver development, and even participation in hardware design. For example, when working on a smart watch project, you need to develop the UI interface in Linux, write the driver program for the sensors, and debug the communication of the Bluetooth module; all these tasks require a comprehensive understanding of both hardware and software.
If you only know Linux but not MCUs and RTOS, it’s like someone who can only use a smartphone but cannot repair one.
When faced with simple issues, such as water damage or a cracked screen, you can only send it for repair; but someone who knows both how to use and repair a smartphone can solve the problem themselves. What companies need are engineers who can “both use and repair”.
Moreover, many small and medium-sized enterprises’ embedded projects do not utilize complex Linux systems; instead, they often implement solutions using MCU+RTOS. For instance, smart locks, smart home sensors, and industrial control devices are in high demand, and the salary is also quite good.
If you skip MCU+RTOS, you are essentially giving up these job opportunities.
Many people want to skip MCU+RTOS and jump straight to Linux because they feel the learning path is too long and want to take shortcuts. However, in embedded systems, there are truly no shortcuts. Here’s a more reasonable learning plan:
First Stage: Start with the 51 microcontroller to build a solid hardware foundation (1-2 months). Although the 51 microcontroller is simple, it is the best choice for understanding hardware. You can start with the most basic GPIO control, implementing simple functions like LED chasers, button inputs, and seven-segment displays. The goal of this stage is to familiarize yourself with the working principles of hardware, how to configure registers, and how to write simple C programs. For example, you can try creating an “electronic clock” project that displays time on a seven-segment display and allows time adjustment via buttons; this project will help you master basic knowledge of timers, interrupts, and IO ports. Although the project is simple, it will help you establish the mindset of “software controlling hardware”. Second Stage: Learn STM32+RTOS to enhance software capabilities (2-3 months). After mastering the 51 microcontroller, you can progress to STM32. The STM32 is more powerful and supports more peripherals, such as SPI, I2C, UART, and ADC. You can attempt more complex projects, such as a “temperature and humidity monitoring system” that collects temperature and humidity data using STM32 and sends it to a computer for display via serial communication. Then, learn RTOS, such as FreeRTOS or UCOS. RTOS will help you understand concepts like multitasking scheduling, semaphores, and mutexes, which are foundational for Linux process management. You can port RTOS onto STM32 to achieve concurrent multitasking, such as simultaneously collecting temperature and humidity data, controlling LED lights, and processing button inputs. Third Stage: Learn Linux to become a full-stack embedded developer (3-6 months). Once you have mastered MCUs and RTOS, learning Linux will be much easier. You can start with Linux basics, learning command line operations, shell programming, and advanced C language, then move on to Linux application development, driver development, and kernel porting. During this stage, you can work on comprehensive projects, such as an “intelligent gateway” that implements data collection, network communication, and data storage using a Linux development board. You will find that the knowledge you learned in MCUs and RTOS can be applied in Linux, making the learning process much more efficient.