Recently, many friends have voted and consulted on how to transition from microcontrollers to embedded Linux development. It seems that there are quite a few readers in the microcontroller and RTOS field. Although I am currently engaged in embedded development related to Linux/Android, I also have about 5 years of experience with bare-metal microcontrollers and RTOS during my studies. I have previously received offers for microcontroller STM32 development positions, so today I will share some views on whether one should transition from microcontroller development to embedded Linux.
1. Have You Really Decided to Transition to Embedded Linux?
The decision to transition from microcontrollers to embedded Linux is a serious one that affects your career development. I can’t make the decision for you, but I can help you list the pros and cons. You need to make the most advantageous decision based on your various circumstances (for example, are there many Linux embedded-related positions in your city? Are you willing to leave your hometown to develop in cities like Beijing, Shanghai, or Shenzhen, etc.). My viewpoint is not that embedded Linux development is absolutely better than microcontroller development; it’s just that based on my experiences, I offer some perspectives.
2. The Biggest Disadvantage of Microcontroller Development Compared to Embedded Linux Is the Lower Average Salary of Entry-Level Positions. I believe this is the main reason why most microcontroller engineers want to transition to embedded Linux. Each technology has its pros and cons, but in terms of entry-level positions, in the same city, microcontroller salaries are 30% to 50% lower than embedded Linux. Many people might compare the high salaries of certain microcontroller bosses (like the famous figures in the industry) or some company executives with those of engineers working in embedded Linux, proving that microcontrollers can also earn high incomes. However, they are making a ‘Tian Ji’s horse racing’ mistake, comparing someone else’s top horse with your average horse. I believe this comparison is very unrealistic; entry-level workers should be compared at the same level. Based on my current observations, in Shenzhen’s entry-level job market, the starting salary for microcontroller (including RTOS) development is around 6K-7K, and reaching 15K is considered high salary, which is hard to break through. Offers above 20K for microcontrollers do exist, but they are rare; I have seen a maximum of 25K offers, which are usually obtained through prestigious companies or universities, or other business backgrounds; the average person really cannot get that. For embedded Linux/Android, the salary is relatively higher, with a starting price of 12K being quite normal. After two years of work, it is common to exceed 15K, and after 3-5 years, breaking through 20K or even reaching 25K is quite common. After 5 years, going to first-tier companies (Huawei, OPPO, VIVO, etc.) can reach 30K, and if you become a module owner expert in a mobile company, breaking 40K is also possible, but it becomes a bit difficult beyond that. Overall, for entry-level workers of the same caliber, embedded Linux salaries are significantly higher than those of microcontroller development. A microcontroller engineer will encounter a bottleneck at 15K, and breaking through 20K is very difficult, while breaking through 20K in embedded Linux is not difficult; it is only when reaching above 25K that one encounters a bottleneck.
3. Are There Many Embedded Linux Positions in Your City? I think this is another significant issue affecting your decision. Most people learn embedded Linux technology primarily to engage in related work, rather than for personal enrichment. However, according to my statistics, although the average salary for embedded Linux is higher than that of microcontrollers, the number of job positions is not as abundant. Shenzhen seems to be the city with the most embedded Linux job opportunities, but microcontroller opportunities appear to be more. In Shenzhen, the ratio of microcontroller to Linux positions is about 6 to 4. In terms of the number of embedded Linux positions in various cities, it ranks as follows: Shenzhen > Shanghai > Beijing > Chengdu = Hangzhou = Suzhou > Dongguan (supported by Huawei) > Zhuhai >= Nanjing = Guangzhou = Wuhan = Xi’an = Fuzhou = Xiamen > Foshan = Changsha = Tianjin = Hefei > Others. I have very little information about embedded Linux development positions in other cities. Therefore, if you are considering a career change, first consider whether you are willing to leave your hometown to work in the above-mentioned cities. Otherwise, even if you learn impressive Linux skills, you may not find suitable positions locally and will have to continue working in microcontroller development.
4. Microcontrollers, Despite Lower Salaries, Offer More Job Opportunities and Are Relatively Friendly to Older Job Seekers. This point is not contradictory; there are many small companies in various industries that use microcontrollers (of course, there are traditional large home appliance manufacturers like Gree and Midea, but emerging high-tech companies like Huawei and SenseTime rarely hire microcontroller engineers). There are many diverse businesses that require more people, but generally, small companies may not have enough funding to offer high salaries. Additionally, the entry barrier for microcontroller development is relatively low (not considering concepts like product stability, EMC, etc., which experienced workers naturally know), and the training period is relatively short (a sophomore student can learn enough in a summer). Therefore, there are still quite a few people who can work at the mid-to-low end, which pulls down the average salary. But this is like Foxconn; they hire many people but complain about a lack of workers. The bosses do not want to raise salaries to control costs, which creates a persistent contradiction between a lack of workers and low pay. However, for older job seekers, since microcontroller positions are indeed numerous, many small companies find it challenging to recruit excellent talent at a high cost-performance ratio. In small companies, there is often no HR involved in human resource planning or age hierarchy construction, and they are not strict about age; older job seekers can find a job as long as they are not picky about salary. Therefore, compared to large companies in Linux, they are more lenient on age issues (possibly because microcontrollers have been around for a while, and there are many older practitioners).
5. Microcontrollers Also Have Some Higher Salary Positions. In the eyes of microcontroller engineers, anything above 20K is considered a high salary. Based on this standard, I have seen some higher-paying positions, but they come with special requirements. A company that makes smart locks based on STM32 RTOS once offered me 20K, primarily because they wanted technical personnel with a background from 985 or 211 universities, which made communication easier. Another well-known unicorn startup offered me 25K for a microcontroller position, but the prerequisite was that I could develop microcontrollers in a Linux environment, and the interview difficulty was quite high. Initially, they were reluctant to offer that much, but after I held out for a week and pretended to have a competing offer from Huawei at the same price, they finally agreed to the 25K offer. Additionally, I have also learned about a senior microcontroller engineer position with an annual salary of 800K (mastering certain industry-specific certification standards). However, overall, it is indeed not easy to obtain higher-paying offers in microcontroller development, and obtaining them is not solely due to your excellent microcontroller skills or debugging abilities; it is often due to your background, education, and other offers driving up the price, as well as mastering specific business competitiveness (you can read my previous article about embedded business competitiveness for more details). These special businesses, diplomas, and backgrounds cannot be easily acquired just by spending time and effort on studying and coding. If you could acquire such skills just by putting in time and effort, they would not be considered threshold technologies.
After listing these points, you should be able to make a decision about whether to transition from microcontroller development to embedded Linux.
6. What Are the Similarities and Differences Between Microcontrollers and Embedded Linux Development?
1. The Advantages Retained When Transitioning from Microcontrollers to Embedded Linux Primarily Lie in Proficient C Language Programming Skills and Rich Experience in Debugging Software and Hardware Interfaces. Since the Linux kernel is written in C, and most Linux applications are also in C, generally, those with microcontroller development experience should not have issues with C. Therefore, when switching, there is no need to consider a language switch. Of course, if you have not systematically studied data structures (which I believe is essential for familiarity with C, even for microcontrollers), you may need to review that. Additionally, experience with real-time operating systems like uCOS or FreeRTOS would be even better, as it will help you not be intimidated when reading large-scale C code (understanding the uCOS kernel does not mean you can immediately grasp the Linux kernel; the Linux kernel is much more complex, and the design concepts are quite different). Furthermore, rich experience in debugging microcontroller and register configurations may help you quickly identify some underlying issues while learning embedded Linux development, saving time.
2. Transitioning from Microcontrollers to Linux Embedded Development Requires Familiarity with a Set of Distinct Development Environments. For most microcontroller engineers, development is primarily done in IDE environments on Windows (although some companies may already use Linux for microcontroller development). Many are less familiar with Linux systems like Ubuntu, so the first hurdle to overcome is not the Linux kernel source code but how to use a Linux system like Ubuntu. Software development on various Linux systems like Debian, Ubuntu, and CentOS is mainly done through command-line operations rather than mouse clicks. Moreover, applications in Linux systems are not integrated like IDEs in Windows; many Makefiles and various services like Samba, SSH Server, and various compilation and linking tools like arm-linux-gcc need to be reassembled and configured by yourself, which may involve various environmental or compilation issues (open-source software can be quite rough), requiring significant time to tinker with. Therefore, for Linux beginners, even with rich C experience from microcontrollers, it can be quite time-consuming to get accustomed to, and one needs to overcome psychological barriers. The Linux system development environment is like a wild horse that does not listen; you must tame it to unleash its value, while the Windows system development environment is more like a docile ordinary horse.
3. The Level of Control Over Code in Embedded Linux Development Is Much Lower Than That in Microcontroller Development; Transitioning to Linux Requires Adapting to Developing in This Low-Control Environment. In microcontroller development, including RTOS, the code volume is usually only a few tens of thousands of lines. Even if not every line has been read, developers can generally have precise control over each module and can easily locate where bugs might occur. However, in embedded Linux development, the Linux kernel alone may have millions or even tens of millions of lines, not to mention various unfamiliar application-level open-source libraries, making it impossible to control most of the code. The development model in embedded Linux is to develop drivers or applications in a situation where most of the code is not yours, and you cannot control most of the code. You often need to search and ask others about unfamiliar elements, which can place you in a state of ‘uncertainty’. Many functions you use may not be familiar to you, and you might only have a vague understanding of their operational mechanisms. Developing in this mode requires excellent searching, communication, and teamwork skills. You can no longer control everything like you did in microcontroller development, and this lack of control can be the most challenging adjustment for microcontroller engineers transitioning to embedded Linux engineers.
4. Embedded Linux Development Requires a Broad Perspective; Do Not Get Lost in the Details. Many microcontroller engineers have a habit of focusing on the working principles of each register, the implementation details of each function, and not letting any ‘if else’ slip by. This approach can be very time-consuming in learning Linux embedded systems and can lead to inefficiency. While attention to detail is good, when a system becomes large enough, those overly focused on details often struggle to manage the system. I have seen many beginners who obsess over every register and every kind of writing in the link script, rigidly applying the 2440 startup process as the only truth for chip startup, trying to apply it to every other chip. Little do they realize that many things are merely habitual practices that have been agreed upon; each company’s chip has its own characteristics, and processes are fixed while people are flexible. Having a broad perspective allows you to quickly familiarize yourself with the knowledge of the entire system; many habitual details will naturally become clear, and your control over the entire system will improve. When you encounter specific detail problems that hinder your progress, you can then address them. Mastery does not mean you know the meaning of every line of code or every register; it means you can make the entire system operate as you intended.
5. What Basic Knowledge Is Needed When Transitioning from Microcontrollers to Embedded Linux?
After discussing so much, it’s time to get to the practical content. What exactly do you need to learn to transition from microcontrollers to embedded Linux? If I do not include this section, I fear you might decide to change careers and immediately pick up a book on Linux kernel architecture and implementation, thinking it is like learning uCOS or other RTOS systems, and end up confused and giving up. In fact, I made similar mistakes when I first studied embedded Linux, and thus I have summarized some lessons learned.
1. You Need to Spend Some Time Familiarizing Yourself with How to Use Linux Systems for Programming Development. Many friends have grown up using Windows computers and probably have not encountered Linux systems like Ubuntu before learning computer programming, and this system does not respond to mouse clicks like Windows; it requires various command-line operations. Moreover, various services and application tools within the system need to be configured according to your requirements. Therefore, learning embedded Linux development is not about rushing into the sea of Linux kernel code but rather starting with how to use the Linux system effectively. You can refer to books like ‘The Linux Command Line’ to learn how to install and use Linux systems and get accustomed to command-line operations. However, I believe learning should be goal-oriented. If you just study each command in ‘The Linux Command Line’ page by page, it will become tedious after a few days. Therefore, I suggest that those with microcontroller development experience should set their first goal as setting up a cross-compilation environment for their microcontroller development board on the Linux system and compiling a bare-metal LED blinking program (without needing to run the Linux kernel), using tools provided by the development board manufacturer to burn it. This task is not difficult; there are many articles online about how to cross-compile microcontroller programs on Linux systems, especially for the STM32 series. You can refer to others’ articles and do it once; in this process, you will become familiar with various common commands, shell, arm-linux-gcc cross-compilation toolchain, Makefile (you can refer to articles by Chen Hao), and other Linux programming environment-related knowledge, thus starting your journey into the Linux world.
2. You Need to Understand How Embedded Linux Systems Run and What Components They Generally Consist Of. Most people transitioning to embedded Linux development are not doing so to develop microcontroller programs on Linux systems but rather to develop Linux drivers or applications. After completing the initial learning step, do not get too caught up in how to write those compilation and linking script formats; instead, quickly focus your energy on Linux system development. Learning embedded Linux system development first requires knowing how a Linux system runs and how to set up a Linux system environment on a development board. This involves components like bootrom, bootloader, uboot, dts, Linux kernel, cmdline, rootfs, etc., as well as various boot methods like nand and nor. Understanding how an embedded Linux system works will allow you to modify and add your drivers and applications further. There are many practical aspects to this, and it may require video materials to guide you through the process quickly. I previously watched videos by Teacher Wei Dongshan on embedded Linux, which had several installments available for free trials and paid content. You can contact sellers on X treasure to learn more; I won’t post advertising links here. Additionally, there are other videos I haven’t watched, so I won’t recommend them casually. In learning embedded Linux, theoretical knowledge should be read gradually, but practical knowledge should be learned through video materials to quickly get started. Reading and practice should progress in a cycle.
3. You Can Try Doing Some Simple Linux Application and Driver Development. Once you have completed the previous two steps, you should have a certain level of professional understanding of embedded Linux development. In learning embedded Linux, I prefer a 60% practice and 40% theory approach. This is because many system environment-related aspects in embedded Linux are not as strictly defined as theoretical formulas in textbooks, and it is difficult to find patterns simply through reading. Additionally, there is a whole set of jargon in the GNU world (you can search what GNU means) within the Linux kernel, and technical experts who write books about Linux kernels and drivers cannot possibly explain all the jargon. Therefore, if you directly open classic books like ‘Advanced Programming in the UNIX Environment’ or ‘Linux Device Drivers’ without prior experience, it is easy to feel lost. I suggest following a video tutorial, such as Teacher Wei Dongshan’s embedded Linux videos, and starting from scratch to write a simple driver and application, allowing your code to run and light up an LED. You don’t need to worry about how the initialization and registration framework functions in the Linux driver are implemented. Through this practical process, you will become familiar with the entire code running environment and the various terminologies in Linux development (system calls, VFS, etc.). This is also a method to achieve learning feedback step by step, enhancing your sense of accomplishment and confidence in learning. In fact, Linux driver development itself is not difficult (the difficulty level should not exceed the formulas in your complex function textbooks), nor is it mysterious; it is just that the entire set of jargon can easily confuse beginners. Familiarizing yourself with this jargon and overcoming fear should enable an average undergraduate student to master it.
4. You Need to Supplement Some Theoretical Knowledge in Computer Science. From what I understand, most microcontroller engineers come from electronics, communications, automation, or mechanical disciplines, with few from computer science backgrounds. These students tend to lack basic theoretical knowledge in computer science, such as data structures, operating systems, computer organization principles, computer networks, algorithms, and the basic principles of compilation and linking, databases, etc. Supplementing theoretical knowledge is a long-term process (which may take 2-3 years), and you do not need to wait until you have completed all computer science theories before looking for a job. You can supplement foundational knowledge while interviewing and job hunting, testing your knowledge in real scenarios. This foundational knowledge will not only improve your technical skills but also help you pass written tests and interviews, determining whether you can break through a salary of 20K in first-tier cities. After acquiring foundational knowledge in computer science and some experience in Linux driver development, learning the Linux kernel is necessary. However, beginners do not need to rush into the Linux kernel source code, as it is quite extensive and profound, requiring time to read books and code gradually. However, having a solid foundation in the Linux kernel can enhance your salary competitiveness.
5. Advice for Those Transitioning Careers with Work Experience.
1. For those transitioning careers with jobs, your advantage is having a stable job and income, while the disadvantage is a lack of sufficient time for learning. With a current job, there is no need to rush into finding a new one. You can maintain a good mindset, remaining calm and steady, and learn while seeking a better opportunity. Of course, having a job does not provide much freedom in terms of time. If the new knowledge you want to learn is not directly related to your current job, I suggest choosing a job with less overtime so that you can free up time after work to learn new embedded Linux knowledge. For those with jobs and some savings, lacking time means you can consider purchasing high-cost-performance paid videos to speed up your entry and learning progress, saving valuable time. Generally, you do not need to master everything before looking for a job; reaching a state where you can self-correct (this term comes from a TED talk about how to learn quickly) and can handle some tasks is sufficient to start interviewing for related jobs. Learning embedded Linux should focus on general foundational knowledge, while specific knowledge related to audio and video drivers and communication protocols can be supplemented once you find a relevant job.
2. How Can Someone With Only Microcontroller Experience Transition to an Embedded Linux Development Job? This is a headache for job seekers who are concerned about relevant work backgrounds. I have the following suggestions:
First, check if the company has a Linux-related department and development plans, and actively try to transfer internally.
Second, see if you can suggest to the technical manager to migrate the microcontroller development environment to Linux systems, allowing you to use Linux systems in your work.
Third, you can try applying to companies that develop microcontrollers in a Linux environment and inquire during the interview whether they do so. If they do, you can join such a company to continue working on microcontrollers while simultaneously familiarizing yourself with Linux.
Fourth, consider interviewing for positions related to bootloaders or firmware development in companies that genuinely develop Linux systems, as bootloaders and storage controllers, power management, and other firmware codes have many correlations with microcontroller bare-metal RTOS development. This ensures that you can contribute to the new job rather than being a complete learner.
Lastly, try interviewing with companies that genuinely develop Linux and have high turnover rates. Such companies can be described as ‘lacking personnel’. I previously worked at an IC manufacturer in Zhuhai, where there were few relevant practitioners, many new graduates were unwilling to develop in small cities, and the company had poor performance in recent years, leading to a high turnover rate. This made it challenging for the company to recruit, and they eventually relaxed hiring standards, willing to train those with only microcontroller experience and no Linux experience. However, my current position is at a well-known large manufacturer in Shenzhen, where the population base is large and the company’s brand and salary are competitive, making competition fierce. Although they claim to lack personnel (in reality, they are too picky), they generally will not give opportunities to candidates without Linux experience.
Finally, while learning embedded Linux, it is best to document the problems you encounter and the code you write in a technical blog and on GitHub, linking them in your resume. This serves as proof to interviewers that you have a certain understanding of embedded Linux, allowing them to further assess your technical level and determine whether to give you an opportunity.
6. Advice for Students Transitioning Careers.
For students, you have the freedom of time but lack money and do not have a guaranteed job.
Of course, time is like toilet paper; it seems abundant, but it runs out quickly, so even with plenty of time, you should plan well and try to learn as much as possible.
Since students lack money, I do not recommend spending tens of thousands on offline embedded training. In reality, the content of the training is generally entry-level knowledge in embedded systems, which may not even be as high quality as a few hundred bucks’ worth of Wei Dongshan’s embedded Linux videos. Additionally, video tutorials are often more flexible in terms of time than training.
Students’ advantage lies in the fact that everyone lacks industry-related experience during campus recruitment, so they will not be assessed on relevant knowledge but rather on foundational computer science knowledge (I even received an offer from an IC manufacturer for a Linux position based solely on my exam scores in operating systems, C language, and data structures without any Linux development experience. Of course, after the campus recruitment, I had more than half a year to purchase Wei Dongshan’s paid videos to rapidly supplement my knowledge). Therefore, students should take advantage of their valuable time to solidify the foundational knowledge mentioned in point 4 above. This way, after starting work, they can focus on business knowledge learning, advancing rapidly in promotions and salary increases without having to revisit foundational knowledge.
Moreover, students may have various competitions related to microcontrollers and embedded systems, potentially winning many awards and receiving praise from teachers and classmates. However, it is essential to remain humble and not become complacent because you have mastered a couple of technologies compared to ordinary classmates (your competitors in interviews are not these classmates with no technical skills). Do not let a few awards lead you to neglect learning fundamental concepts like data structures, operating system principles, etc. If you have not published high-level papers in well-known journals or achieved high scores in internationally recognized competitions like ACM, Kaggle, or ISLVRC, the awards from other domestic competitions may not carry much weight in interviews and actual work. Interviewers tend to prefer students with solid foundational skills and strong potential rather than those with a pile of domestic awards but lacking knowledge of concepts like time complexity, linked lists, stacks, and MMU virtual address space.
Finally, I hope this article can help those who are in a state of confusion.