Follow Baiwen Technology, choose to pin or star
Don’t miss any exciting content
—
Author: Embedded Veteran Huo Ge
Authorized reprint from the WeChat public account of Embedded Veteran’s Career Path (ID: ict_embedded), with added content and modifications.
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 working with microcontrollers and RTOS. Although I am currently engaged in embedded development in Linux/Android, I also have about 5 years of experience with bare-metal microcontrollers and RTOS during my studies, and I have previously received some offers for microcontroller STM32 development, so today I will share some views on whether to transition from microcontroller development to embedded Linux.
1. Have you really decided to switch to embedded Linux?
Whether to transition from microcontrollers to embedded Linux is a serious decision that affects career development. I cannot make the decision for you, but I can help you list the pros and cons. You need to make the most beneficial decision based on your various environments (for example, are there many embedded Linux-related positions in your city? Are you willing to leave your hometown for development in big cities like Beijing, Shanghai, Shenzhen, etc.?)
My view is not that embedded Linux is absolutely better for career development than microcontroller development; I just provide some insights based on my experiences.
1. The biggest disadvantage of microcontroller development compared to embedded Linux is that the average salary for basic labor positions is relatively low.
I believe this is the main reason why most microcontroller engineers want to transition to embedded Linux. Each technology has its own advantages and disadvantages, but in terms of basic labor, in the same city, the salary for microcontrollers is 30% to 50% lower than that for embedded Linux.
Many might compare the high salaries of certain microcontroller bosses (like Huo Ge from Wildfire, Zhou Ligong, etc.) or some company executives with those of engineers working in embedded Linux, proving that microcontrollers can also earn high salaries.
However, they are making the mistake of comparing a top horse with an average horse, which is very unrealistic. Basic labor should be compared with basic labor.
From my investigation, in the basic job market in Shenzhen, the starting salary for microcontroller (including RTOS) development is around 6K-7K, and reaching 15K is considered high; it is very difficult to break through.
Offers above 20K for microcontroller positions do exist, but they are rare. I have seen a maximum of 25K for microcontroller offers, but those are usually obtained through well-known companies, prestigious universities, or other business backgrounds; an average person really cannot get them. For embedded Linux/Android, the salary is significantly higher, with a starting price of 12K being normal, and most people can break through 15K after 2 years, and it is common for 3-5 years to exceed 20K or even reach 25K. After 5 years, going to top-tier companies (like Huawei, OPPO, VIVO, etc.) can reach 30K, and if you become a module owner expert in a mobile phone company, breaking through 40K is also possible, but going higher becomes difficult.
Overall, for workers at the same level, embedded Linux salaries are significantly higher than those for microcontroller development. Microcontroller engineers face a bottleneck at 15K, and breaking through 20K is very difficult, while breaking through 20K in embedded Linux is not a challenge, with the bottleneck appearing above 25K.
2. Are there many embedded Linux positions in your city?
I believe this is another major 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, while the average salary for embedded Linux is higher than that for microcontrollers, the number of job positions is not as abundant.
Shenzhen appears to have the most embedded Linux job opportunities, but it seems there are even more opportunities for microcontrollers. In Shenzhen, the ratio of microcontroller to Linux positions is approximately 6 to 4.
From the perspective of the number of embedded Linux positions in various cities, they rank as follows: Shenzhen > Shanghai > Beijing > Chengdu = Hangzhou = Suzhou > Dongguan (backed by Huawei) >= Zhuhai >= Nanjing = Guangzhou = Wuhan = Xi’an = Fuzhou = Xiamen > Foshan = Changsha = Tianjin = Hefei > Others. I rarely learn about embedded Linux development positions in other cities.
So if you are considering a career change, first consider whether you are willing to move to one of the above cities. Otherwise, even if you learn impressive Linux skills, you may find it difficult to find suitable positions locally and be forced to continue working in microcontroller development.
3. Microcontrollers may offer lower pay, but they have 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 require microcontroller developers (of course, there are traditional home appliance giants like Gree and Midea, but few emerging high-tech companies like Huawei and SenseTime hire microcontroller developers). The diversity of businesses means more demand, but generally, small companies may lack funds to offer high salaries, and the entry barrier for microcontroller development is relatively low (not considering product stability, EMC, etc., concepts that someone with work experience would naturally know; I am only referring to the training threshold for learning to use microcontrollers for programming), and the training period is relatively short (a sophomore student can learn enough in a summer). This results in a large number of low-end workers, which lowers the average salary.
However, this is similar to Foxconn, which hires many people but complains about a lack of workers; the boss simply does not want to raise wages to control costs. This is a perpetual contradiction between having a shortage of workers and low pay. However, for older job seekers, the abundance of microcontroller positions makes it easier for many small companies to find excellent candidates at a high cost-performance ratio. In small companies, there is often no HR managing human resources planning or age hierarchy, so they are less strict about age; as long as older job seekers do not have salary demands, they can find jobs. Thus, compared to large companies working with Linux, microcontroller positions are more lenient regarding age (perhaps because microcontrollers have been around longer, there are more older practitioners).
4. There are also some high-paying positions in microcontrollers.
For microcontroller engineers, a salary above 20K is considered high. Based on this standard, I have seen some high-paying positions, but they often have special requirements.
For instance, a company working on smart door locks using STM32 RTOS offered me a 20K position, mainly because they wanted technical personnel with a background from 985 or 211 universities to ensure consistent communication, which is why the salary could reach 20K.
Additionally, a well-known unicorn startup offered me a 25K 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 unwilling to pay that much, but after I kept them waiting for a week, claiming to have received an offer from Huawei at a similar price, they finally agreed to the 25K offer.
I also learned of a senior microcontroller engineer position with an annual salary of 800K (who mastered certain industry-specific certification standards). However, overall, high-paying offers for microcontrollers are indeed not easy to obtain, and even when they are, it is not solely due to one’s microcontroller skills or debugging abilities, but rather because of one’s background, education, and other offers that help negotiate higher salaries, as well as possessing special business competitiveness (for more on embedded business competitiveness, you can read my previous article about it). These special businesses and credentials cannot simply be acquired through time spent studying and coding; if one could easily obtain such skills through hard work, they wouldn’t be considered high-barrier skills.
Having listed the above points, I believe you should be able to decide whether to transition from microcontroller development to embedded Linux.
2. What are the similarities and differences between microcontrollers and embedded Linux development?
1. The main advantages retained when transitioning from microcontrollers to embedded Linux are the proficient C programming skills and rich experience in debugging low-level software and hardware interfaces.
Since the Linux kernel is written in C, and most of the lower-level applications in Linux are also in C, those with microcontroller development experience should not have issues with C. Therefore, during the transition, there is no need to worry about switching languages. However, if you have not systematically studied data structures (which I believe is essential for mastering C, even for microcontrollers), you may need to brush up on that.
Additionally, experience with real-time operating systems like uCOS or FreeRTOS would be beneficial, as it helps you not be intimidated when looking at large-scale C code (although understanding uCOS does not mean you can immediately master the Linux kernel, as the Linux kernel is significantly more complex and has a different design philosophy).
Furthermore, rich experience in low-level debugging and register configuration for microcontrollers may help you quickly identify lower-level issues when learning embedded Linux development, saving you time.
2. Transitioning from microcontrollers to embedded Linux requires familiarity with a set of distinctly different development environments.
For most microcontroller engineers, development mainly occurs in IDE environments on Windows (though some companies may already be using Linux for microcontroller development). Many have little exposure to Linux systems like Ubuntu, so the first hurdle to cross is not the Linux kernel source code, but rather how to use a Linux system like Ubuntu.
In various Linux systems such as Debian, Ubuntu, and CentOS, software development is primarily done through command-line operations rather than mouse clicks. Moreover, the applications in Linux are not integrated like IDEs in Windows, meaning many Makefiles and various services like Samba, SSH Server, and arm-linux-gcc are like components in IDE software that need to be reassembled for use, and you may encounter various environmental and compilation issues (this is often the case with open-source software). You will need to tinker with them, which can take a considerable amount of time.
So, for Linux beginners, even with rich C experience in microcontrollers, getting accustomed can be time-consuming, and overcoming psychological barriers is essential. The Linux development environment is like a wild horse that doesn’t listen; taming it is necessary to unleash its value, whereas the Windows development environment is more like a docile ordinary horse.
3. The level of control over code in embedded Linux development is much lower than in microcontroller development, requiring adaptation to develop in this environment of lower control and insecurity.
In microcontroller development, including RTOS, the code volume is generally only a few tens of thousands of lines; even if not every line is read, developers can generally pinpoint where bugs may arise. However, in embedded Linux development, the Linux kernel alone has millions or even tens of millions of lines, not including various unfamiliar application-layer open-source libraries, making it impossible to control most of the code.
The development model for embedded Linux is to develop drivers or applications in a context where most of the code is not yours, and you cannot control most of it. You will often encounter unfamiliar elements requiring extensive searching and inquiry. This development model places individuals in an ‘uncertainty valley,’ where many functions you use may have their implementation details unknown, and you might only grasp their operational mechanisms.
Developing in this model requires excellent search, communication, and team collaboration skills; you can no longer control everything globally as in microcontroller development.This sense of insecurity regarding lack of control is what microcontroller engineers must adapt to as they transition to embedded Linux engineers.
4. Embedded Linux development requires a broader perspective, avoiding getting lost in the details.
Many microcontroller engineers have a habit of focusing on the working principles of each register, the implementation logic of each function, and not letting any if-else statement go unnoticed while programming.
This approach can be very time-consuming during Linux embedded learning, leading to inefficient results. While paying attention to details is beneficial, when a system becomes large enough, those overly focused on details often struggle to manage the system.
I have seen many beginners obsess over every register and every writing method in linking scripts, such as treating the startup process of the 2440 chip as the only truth for all chip startups, applying it uniformly to other chips. Many practices are merely conventional methods established by humans; each company’s chips have their unique characteristics, and processes are fixed while humans are flexible.
Grasping the big picture allows one to quickly familiarize oneself with the overall system knowledge, and many habitual details will naturally become clear. When encountering specific detail issues that hinder your progress, you can then attempt to address them. Mastery does not mean knowing the significance of every line of code or register; rather, it means being able to make the entire system operate according to your intentions.
3. What basic knowledge is needed when transitioning from microcontrollers to embedded Linux?
After discussing so much, it’s time to get to the real content. What do you need to learn to transition from microcontrollers to Linux embedded development? If this section is missing, I worry that 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, which are also C code, only to find it confusing and give up. I made similar mistakes when I first learned Linux embedded, so I have summarized some experiences and lessons.
1. You need to spend some time familiarizing yourself with programming development using Linux systems.
Many friends have grown up using Windows computers; before learning computer programming, they likely had little exposure to Linux systems like Ubuntu, which does not respond to mouse clicks like Windows, requiring various command-line operations. Additionally, various services and application tools need to be configured according to your needs.
Thus, learning embedded Linux development should not be about diving headfirst into the sea of Linux kernel code, but rather about mastering the Linux system first.
You can refer to books like “Bird Brother’s Linux Cookbook” on how to install and use Linux systems and learn to use the command line. However, I believe learning should be purposeful; if you try to learn every command from “Bird Brother’s Linux Cookbook” page by page, you will find it tedious after a few days.
Therefore, I suggest that those with microcontroller development experience set their first goal as establishing a cross-development environment for their microcontroller development board on the Linux system, compiling a bare-metal LED lighting program (without needing to run the Linux kernel) and flashing it using tools provided by the board manufacturer.
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 reference others’ articles to do it once, during which you will become familiar with various commonly used commands, shell, arm-linux-gcc cross-compilation toolchain, Makefile (you can refer to Chen Hao’s article separately), and other knowledge related to the Linux programming environment, thus starting to enter the world of Linux.
2. You need to understand how the embedded Linux system runs and what components it generally consists of.
Most people transitioning to embedded Linux development do so not to develop microcontroller programs on Linux systems but to create Linux drivers or applications. After completing the first step of entry, you should not get too caught up in how to write compilation and linking script file formats but rather focus your energy on Linux system development as quickly as possible.
Learning embedded Linux system development begins with understanding 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, and various boot methods such as nand boot and nor boot. Understanding how an embedded Linux system works will allow you to modify and add your own drivers and applications.
This area has many practical aspects, and you may need video materials to guide you through the process quickly. I previously watched teacher Wei Dongshan’s embedded Linux video series, which consists of several episodes with free trials and paid options; you can contact sellers on Taobao to learn more, but I won’t post advertisement links here.
There are also other videos that I haven’t seen, so I won’t recommend them casually. In embedded Linux learning, theoretical knowledge needs to be read gradually, but practical knowledge still requires video materials to guide you through the process quickly, creating a cycle of reading and practice.
3. You can try to develop some simple Linux applications and drivers.
Having gone through the previous two steps, you should have a certain level of professional understanding of embedded Linux development. In embedded Linux learning, I prefer learning by doing, with 60% practice and 40% theory. Many system environment-related aspects in embedded Linux are not strictly theoretical formulas as seen in textbooks, and it can be challenging to find patterns solely through reading. Additionally, the Linux kernel contains a whole set of GNU (you can search what GNU means) jargon that technical experts writing books on Linux kernels and drivers cannot possibly explain all of, making it easy for beginners to feel lost without prior experience.
I suggest following a video tutorial, such as teacher Wei Dongshan’s embedded Linux video series, 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, registration, and other framework functions in Linux drivers are implemented.
Through this practical process, you will familiarize yourself with the entire code execution environment and various jargon in Linux development (such as system calls, VFS, etc.). This is also a method to receive positive feedback from your learning, increasing your sense of achievement and confidence.
In fact, Linux driver development is not difficult (its difficulty does not exceed the formulas in your complex variable function textbook), nor is it mysterious; it is simply a whole set of jargon that can easily confuse beginners. Familiarizing yourself with this jargon and overcoming fear can enable an average undergraduate with normal intelligence to master it.
4. You need to supplement some theoretical knowledge of computer science.
From what I understand, most microcontroller engineers come from electronics, communications, automation, or mechanical professions, with few from computer science backgrounds. These professionals may lack fundamental 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 don’t need to wait until you have mastered all computer science theories before seeking employment. You can supplement foundational knowledge while interviewing and job hunting, using this to test your foundational knowledge.These foundational skills not only enhance your technical capabilities but also help you pass written exams and interviews, determining whether you can break through a salary of 20K in first-tier cities.
Once you have a foundational knowledge of computer science and some experience in Linux driver development, learning the Linux kernel becomes necessary, but beginners should not rush into the Linux kernel source code. The kernel is complex and requires time to read books and code gradually; it cannot be learned quickly. However, a solid foundation in the Linux kernel can enhance your salary competitiveness.
4. Advice for experienced career changers.
1. For those with jobs, your advantage is having a stable job and income, while the disadvantage is a lack of sufficient free time to learn. With your current job, you don’t need to rush to find a new one; you can maintain a good mindset, staying calm and not impatient, allowing you to learn while looking for a suitable job.
Of course, those with jobs may not have time freedom. If the new skills you want to learn are not directly related to your current job, I recommend choosing a job with less overtime, allowing you to free up your evenings for learning new embedded Linux knowledge.
Those with jobs, having some savings, lack time. Thus, in learning, it is worthwhile to invest in high-cost-effective paid videos to accelerate your learning progress, saving valuable time. This is also a way to exchange money for time.
Generally, you don’t need to be an expert before seeking employment; reaching a state where you can self-correct (this term comes from a TED talk about how to learn quickly) and can perform some tasks is sufficient to interview for related jobs. Learning Linux embedded primarily focuses on general foundational knowledge, while the specialized knowledge related to audio and video drivers and communication protocols can be supplemented once you have found a relevant job.
2. How to land an embedded Linux development job through social recruitment with only microcontroller experience and no Linux development experience?
This is a headache for job seekers who are valued for their relevant work background. Here are a few suggestions:
First, check if the company has a Linux-related department and development plan, and actively attempt internal transfers.
Second, see if you can suggest to the technical manager to migrate microcontroller development environments to Linux systems, allowing you to gain Linux system experience while working.
Third, try interviewing with companies that develop microcontrollers in a Linux environment, asking the interviewer if they do so during the interview. If they do, you can join a company that uses Linux to develop microcontrollers, continuing to work in microcontrollers while familiarizing yourself with Linux.
Fourth, try interviewing for positions related to bootloader or firmware development in companies that genuinely develop Linux systems, as bootloaders and storage controllers, power management, and other firmware codes have much relevance to bare-metal RTOS development. This ensures you can contribute in your new role rather than being a complete learner.
Finally, consider interviewing with truly Linux-focused companies that have high turnover rates and low employee retention. These companies, described as “short-staffed,” often relax hiring standards due to the difficulty of finding talent. I previously worked at an IC manufacturer in Zhuhai, where there were few industry practitioners, and many fresh graduates were unwilling to develop in smaller cities. Coupled with the company’s poor performance in recent years and high turnover, they found it hard to recruit talent, eventually relaxing hiring standards to welcome those with only microcontroller experience.
Of course, at my current well-known large company in Shenzhen, due to a large population base, competitive brand and salary, competition is fierce. Although they claim to be short-staffed (actually, they are too picky), they generally do not offer opportunities to candidates without Linux experience.
Lastly, while learning embedded Linux, it’s best to document the problems you encounter and the code you write in a technical blog and on GitHub, attaching relevant links to your resume. This serves as proof to interviewers that you have a certain understanding of embedded Linux, allowing them to better gauge your technical level and decide whether to give you an opportunity.
5. Advice for students transitioning to new careers.
For students, you have the freedom of time but lack money and a safety net job.
Of course, time is like toilet paper; it seems abundant, but it diminishes quickly as you use it. Thus, even with ample time, you should plan wisely and try to learn as much as possible.
Since students lack funds, I do not recommend spending thousands on offline embedded training, as the content typically covers only entry-level knowledge, and the quality may not exceed that of the few hundred RMB Wei Dongshan embedded Linux video series. Moreover, video tutorials may be more flexible in terms of time than training.
The advantage of students is that no one has industry experience, and during campus recruitment, they won’t assess your industry-specific knowledge but will focus more on fundamental computer knowledge (I even landed an IC manufacturer Linux offer based on my scores in operating systems, C language, and data structures, despite having no Linux development experience. Of course, after campus recruitment, there was still half a year during which I purchased Wei Dongshan’s paid videos to rapidly supplement my knowledge).
Thus, students should take advantage of their precious time to solidify the foundational knowledge mentioned in point 4, allowing them to focus on learning business knowledge and accelerate promotions and salary increases after entering the workforce, rather than needing to retrain due to weak foundational knowledge.
Additionally, students may participate in various microcontroller embedded competitions, potentially winning many awards and receiving praise from teachers and classmates. However, it’s crucial to remain humble and not become overconfident just because you’ve mastered a few more technologies than ordinary classmates (your competitors in interviews will not be those who lack technical skills). Do not let a few awards lead you to feel superior and distract you from studying fundamental concepts like data structures and operating system principles.
Unless you have published high-level papers in reputable journals or achieved high scores and rankings in internationally recognized competitions like ACM, Kaggle, or ISLVRC, other domestic competition awards may not hold much persuasive power in interviews or practical work.Interviewers prefer students with solid fundamentals and strong potential for growth, rather than those who have a pile of domestic awards but are clueless about time complexity, linked lists, stacks, MMU virtual address space, and other concepts.
Finally, I hope this article can help those who are in a period of confusion.
In addition to my article, I would also like to share recent Q&A content from teacher Wei Dongshan regarding a student’s career concerns, which may resonate more when compared to the above article.
Student Cleo asked:
Teacher Wei Dongshan replied:
1. High threshold:
From a technical perspective, you need to understand hardware, know English, and software, so the threshold is high;
From a position perspective, there are definitely fewer positions in low-level systems compared to APP positions, and experience is required;
Many people have a misconception about learning Linux, thinking they only want to do drivers.
In reality, Linux encompasses a vast range, and drivers are just a small part of it.
In actual work, especially in small and medium enterprises, you need to master everything from top to bottom;
The approach in large companies like Huawei and ZTE is for each person to specialize in one area,
but these individuals often struggle to adapt to the outside world after leaving large firms,
as small and medium enterprises cannot afford such high configurations.
2. The tasks you perform in actual work can be compared with your microcontroller development,
but running a Linux system allows for many more tasks.
Take smart home development as an example.
Assuming the following usage scenario:
You can remotely operate a remote control to design the air conditioning through your phone.
This involves the following five products:
Phone —- Server —- Smart Gateway at home ——– Remote Control —— Air Conditioning.
Thus, this complete product requires development:
a. Phone APP
b. Server: acts as an intermediary between the phone APP and the smart gateway at home, and can also manage users
c. Smart Gateway: connects with the phone APP, and then operates the remote control
d. Remote Control: receives data from the gateway and sends infrared signals to the air conditioning
e. Air Conditioning: we need to understand the infrared protocol of the air conditioning
In these products, the remote control is simply a microcontroller; apart from its traditional functions, it can also communicate with the smart gateway via Bluetooth, Zigbee, etc.
The smart gateway is generally a router running Linux, which may also have Bluetooth or Zigbee modules,
taking on the responsibility of accessing the “internet”;
Server: manages user registration and device management (one user may have multiple smart hardware) and cost management.
You can see that there are many software development tasks involved. In the microcontroller era, one person could complete all the work;
However, in the Linux field, everyone must collaborate.
In actual development processes, it involves communication, coding, self-testing, and joint testing.
In the past, one person handled everything; now you have to interact with more people.
Therefore, you need to understand more concepts.
From this perspective, even if you only do APP development, you should understand some concepts of low-level drivers.
3. Experience:
After completing the first three video series, you will have encountered the knowledge needed in actual work.
However, you may still lack experience and the ability to use it flexibly.
I suggest that while studying, you can use another different board to write the programs involved on the new board.
Finally, do not focus solely on drivers.
Look at the entire system; whatever industry you want to enter, learn accordingly:
a. Low-level systems and drivers are foundational; first grasp these concepts
b. Then learn about APP development relevant to that industry, at least understanding some conceptual knowledge
In the future, whether you want to work on low-level or APP development, having an understanding of the entire system will make it easier to find a job.
–END–
You might also be interested in these articles:
Interview Guide for Electronics Communication and Embedded Engineers
Useful Work Tips Compilation
Linux Device Drivers: Kobject, Kset
How to Ask Questions Smartly
How to access selected quality articles from this public account?
Please reply “m” in the public account backend to get it.
