Dragging my weary body home, Xia Tian bounced out of the house, smiling happily: “You’re back!~” The man loosened the collar of his shirt, looking disgusted as he dodged: “What do you want again? I told you, I really hate you.” Xia Tian stood there, awkwardly rubbing her hands: “But you also said you liked me.” The man frowned: “Don’t get ahead of yourself, when was that?” Xia Tian smiled: “Well… back when you called me during the summer vacation.”
“Stay true to your original aspiration and you will achieve your goal.” Only by not forgetting your initial thoughts can you complete your dreams from start to finish. It sounds simple, but dreams are ultimately glamorous yet fragile. In the face of the bustling world, how easy is it for an ordinary person to protect their dreams with a frail body?
I am based in Hangzhou. After graduating with my bachelor’s degree, I worked at a small company mainly developing hardware systems for logistics monitoring management, primarily electronic locks and supporting system devices, which fall under the Internet of Things category. During my time there, I performed well and achieved some results, gaining recognition from the general manager and other key personnel (mainly technical staff) in the company. In 2014, due to disputes among shareholders, the company ceased operations. Under the general manager’s planning, several of us core members re-registered a company to continue the original products, making me a partner. The company has been running for almost a year now, but I have withdrawn due to technical direction issues and economic pressure, and I am now self-studying Linux to prepare for a career transition.
My work experience over the past three years has been roughly as follows. When I first graduated and was looking for a job, my grades were average, I wasn’t very skilled in hardware, and I had never designed a circuit board (I still haven’t). However, I had participated in a Freescale smart car competition during college, so I was relatively familiar with programming microcontrollers. I then prepared for the graduate entrance exam, but due to insufficient review time and an inability to concentrate, I failed. I decided to work instead, as I originally wanted to engage in embedded Linux work but lacked the necessary skills, which made it unlikely for me to get hired (I might also fall victim to training institutions). Later, I joined this company, and during the interview, I had a pleasant conversation with the general manager. We didn’t discuss technical matters in great detail, just briefly mentioned the smart car project I worked on at school, and then I was hired. I also interviewed at a medium-sized company, passed the initial interview and technical test, but in the end, I chose this small company that was IoT-related, thinking I might encounter Linux in the future, especially since the general manager showed such great sincerity.
The first two years after graduation were my technical growth period. Initially, I worked on microcontrollers + RF modules, using a semi-finished electronic lock program with relatively simple functions, mechanical unlocking, and sending data wirelessly to the corresponding collection node. The wireless communication was also unidirectional (from the node to the collection terminal). Soon after, the general manager decided to develop locks with more functions, mainly characterized by ensuring low power consumption while enabling bidirectional communication between the node and the collection host AP to allow for remote unlocking. I took on this task, spending over two months figuring out and debugging the Wake On Radio (WOR) technology for the hardware. The idea was that the node would usually be in a low-power state and would receive special data from the host to wake it up when there was a command sent. The node would then receive the command and execute it within a short time. After communicating with senior colleagues, I upgraded the hardware WOR to software WOR, where the hardware WOR relied on some registers of the RF chip and its integrated WOR function, while software WOR was entirely controlled by software. Since I enjoy building architectures, and for future functional expansion or portability, I also looked into TI’s public simpliciTI wireless protocol stack to learn how foreign developers write code. I managed to port the MRFI layer of simpliciTI that deals with the RF bottom layer and designed a network layer based on a star topology according to my product’s technical requirements, ultimately forming a small protocol stack. Compared to TI’s simpliciTI, this protocol stack’s advantage lies in its ability to achieve bidirectional communication under low power consumption, mainly by integrating WOR. By calling APIs, all functions can be realized, and the application layer does not need to intervene in the RF bottom layer operations, which are fully controlled by the protocol stack. For example, when sending data, you can choose parameters through the API to determine whether the receiving party needs to confirm receipt. If so, the protocol stack will automatically complete some tasks, and the upper layer only needs to check the API return value to determine whether the receiving party has confirmed receipt, etc. This protocol stack was specifically designed for a relatively old RF chip, but it can also be used with newer, higher-performance RF chips, although hardware porting is required, which I haven’t done because the company has no plans to change the RF chip.
I mentioned this protocol stack to illustrate that it is my most notable achievement and has contributed the most to my technical growth. Since then, the general manager has trusted my programming abilities, whereas previously he needed to review my code; now he doesn’t have to. The protocol stack was basically stable by early 2013. Before that, I had been secretly writing it for about 2-3 months, and after some debugging and optimization, when I finally presented it, I felt that both the general manager and the hardware supervisor were quite impressed.
During this time, I was also working on the development of wireless hosts. Initially, the microcontroller and nodes used were the same, but later, due to changes in the host’s functional definitions, I switched to an NXP chip, and I finally began to engage with ARM architecture Cortex-M3 and OS-related topics—specifically, u/Cos. The company also had vehicle positioning hosts and platforms, but I was not responsible for that area (and never was, because I didn’t write the host’s code, which did not conform to my coding standards and lacked a framework, making it hard to understand. I actually didn’t want to look at it, but due to some project requirements, I managed to understand it twice, but then forgot everything). However, I observed it daily and was eager to try it out. Later, I downloaded documents from ARM to understand the CM3 architecture (of course, I’ve forgotten most of it now), and I also read the English documentation written by the author of u/Cos. I became familiar with most aspects of uCos (except for some that I didn’t use). I even wrote assembly code to port the uCos system based on the documentation. Later, the host was upgraded to run uCos, and I ported my own protocol stack. More effort was spent on the application layer than on the protocol stack, but after all, it was application layer work, so there isn’t much to say about it.
In 2014, the company moved to a larger location, stating that the major shareholder intended to increase investment and expand the company. At that time, the general manager said he planned to let me work with Linux, as the company was preparing to upgrade some products to run Linux for more complex applications. I was naturally delighted because I had a background in microcontrollers and some knowledge of OS and ARM, so learning it shouldn’t be too difficult. However, Linux is quite extensive, and I knew I would have to spend a lot of time gradually digesting it. Due to the expansion, the company needed to hire new employees. From the end of 2013 to the beginning of 2014, the general manager asked me to interview candidates. I encountered undergraduates, graduates, some talented individuals, and some who voluntarily stated they were unqualified and left after coming to the company for an interview. Regarding Linux, since I didn’t understand it, I only mentioned it casually, but I found that many Linux candidates came from training institutions, and many had only a superficial understanding, not really suited for technical roles. However, I did meet one talented individual who was proficient in Linux before graduation and wanted to deepen his knowledge at a training institution. He later told me that he didn’t learn much at the training institution. At that time, I wanted the company to hire a Linux expert to guide me because I knew I would encounter many detours learning it on my own. However, things did not go as planned; the candidates I wanted didn’t come (I don’t know if it was due to the low salary offered or because they thought our small company had no prospects). In the end, we hired a mediocre fresh graduate (who consistently failed to complete any tasks assigned to him, working in a perfunctory manner, and even though he knew he hadn’t finished his tasks, he still left on time every day). I felt deceived, but it seemed the general manager was deceived as well, which once again proved the truth that cheap things are often of poor quality. Initially, it was difficult to recruit people, and I began to doubt the general manager’s ideas and the company’s financial situation (my salary was also relatively low; I had been holding on out of some hope, but my salary had been gradually increasing since mid-2013). By the end of 2013, things did not go as expected. The general manager later decided that the smart lock needed to be integrated with an app, and since Android was already very popular, I began working on new things, not Linux, but Bluetooth BLE4 that supports low-power hardware.
We used TI’s BLE4.0, and I was responsible for developing the Bluetooth smart lock. Regarding TI’s BLE4.0, if you want to delve deep, it requires quite a bit of time. However, if you are not using very complex functions and don’t want to understand the deeper Bluetooth protocol stack, 2-3 months is about right. However, I wasn’t very enthusiastic about this because it was essentially TI’s software architecture built to support the BLE4.0 protocol based on their hardware platform. You only need to understand the top-level architecture and don’t need to delve into the deeper Bluetooth protocols. However, during development, I encountered many issues because this technology had just emerged, and even now, it is still based on TI’s example projects that have been modified and added to, so it could not meet various hardware requirements, and there were also some issues with TI’s software architecture, such as data corruption or tampering occurring under high data flow with UART supported by DMA. Additionally, in our project, the serial port used was not the example project’s serial port 1 but serial port 2, so I had to modify the lower-level code, which took me quite a bit of time. To resolve this, I spent a lot of time reading the lower-level code and related materials as well as debugging. Another issue was that your application layer code could not occupy too much MCU time because the Bluetooth protocol stack’s lower-level requires sufficient MCU time; otherwise, your Bluetooth connection would drop and become unrecoverable (it can only be restarted). Since this technology was relatively new, compatibility was still poor, and flexibility was lacking. The most critical point was that it was still a microcontroller, and overall, I was not very interested!
At that time, internal conflicts began to arise within the company, mainly due to disputes over interests and power. The general manager wanted me and a colleague to hold shares to control the company. He had a falling out with one shareholder (a female shareholder), and in the end, the company ceased operations. Under the general manager’s planning, I resigned first, followed by several core personnel. The general manager and I then joined another company in Ningbo (the general manager took me there; in my view, although it was a small company, it was quite wealthy and the environment was good). Initially, we agreed to temporarily go there until this company established a subsidiary in Hangzhou, which we would manage. However, we later discovered that our general manager had been deceived, so we left. I won’t go into the details of what I accomplished during that time; in short, I returned after less than a month.
In the end, the original core members registered a company in Hangzhou to continue the original products. There were only four or five of us, and only one was engaged in hardware, the original hardware supervisor. After the company was established, the hardware supervisor worked for more than a month before falling ill; his health was poor. Since I had no hardware skills and could only understand the schematics, the project was severely delayed. By early 2015, the smart lock system we developed had a high failure rate, and due to poor business relations and customer handling, we lost that client, which was a major source of profit for the company. By May or June of this year, the company had spent all the money earned in 2014 and was almost out of cash. According to an agreement among shareholders: when funds are insufficient, the priority is to ensure the payment of ordinary employees’ salaries, and shareholders do not receive salaries. By the end of June, I had not received a salary for two months. In late 2013, with the support of my family, I bought a house in Hangzhou, becoming a mortgage slave, with a monthly mortgage of over 5K that my family and I split evenly. I had also started a family. Due to my low salary and the fact that I had invested my limited savings into the company along with my wife’s, I ultimately chose to withdraw from the company due to its prospects, my technical future, and economic pressure. Currently, I am unemployed at home, self-studying Linux to prepare for a career transition.
In fact, the hardware supervisor’s illness had a significant impact. When I left, I only left behind a semi-finished Bluetooth lock (which supported low power consumption and integrated GPS and GPRS modules), and the software had not yet been finalized or stabilized for testing, and there were still some unresolved hardware issues. The hardware supervisor later developed severe pneumonia and had not come to the company for normal work since before I left; he only occasionally came to help us solve problems. I personally do not like to give up, but the reality is quite dire:
1. The general manager’s current product positioning is focused on Bluetooth, which is inconsistent with my technical aspirations. Moreover, the things I am currently working on are nearly reaching the limit of my technical improvement. I have also been waiting for the day I can work with Linux (I now realize that I was too naive; I should have thought things through when the company was first established, but I was just following my feelings with the general manager and the spirit of entrepreneurship, making it difficult to refuse);
2. The company’s current situation is concerning. Due to the lack of hardware personnel, the team is not harmonious, and the production and processing of original products are complex and costly. In the end, I basically became a producer of products, doing unrelated tasks such as soldering boards and troubleshooting quality issues with hardware boards. The general manager even had me responsible for liaising with clients regarding production and installation matters to help me improve my communication skills, something I was not interested in at this stage. Thus, my研发心态 (research and development mindset) has vanished, and with the company being out of funds and unable to pay salaries, it has gradually devolved into a trading nature, with研发 (R&D) nearly regressing to the point that I feel I have no value in R&D anymore;
3. The team lacks cohesion, and the atmosphere is poor. There are several shareholders: one of my colleagues, one of my superiors, and one hardware person (who has been ill). Therefore, I mostly interact with my colleague (the general manager mainly communicates with研发). He is responsible for various company matters. He joined the original company a year later than I did but is slightly older. Initially, everything was fine, and we worked happily together. However, he is just an employee and hasn’t shown much initiative. When we started our company, for some reasons, the general manager made him the legal representative (in reality, the general manager is the boss; he originally held fewer shares, but later the general manager said to be fair, he would give me and my colleague equal shares, which I agreed to). Since the product’s failure rate was high, he has been burdened with many troubles, and I feel his attitude towards me has been deteriorating. Gradually, some of his incompatible traits have become apparent, and I feel increasingly unhappy working with him. Additionally, I remember the general manager once said to me during a private conversation: “Currently, your研发 (R&D) team’s contribution to the company is zero because the product研发 (R&D) progress is slow, and there are many issues that cannot be released as products. We are relying on installation personnel and salespeople to run a few other products and some resold products to cover your研发 (R&D) salaries” (this is not his exact wording, but that was the meaning). Although this statement is not wrong, it was a significant blow to my morale;
4. Personal financial issues have become critical. If this continues for another two or three months, I will not be able to pay my mortgage.
In fact, after the company was established, I gradually changed my view of the general manager; it has not been as favorable as before, and I no longer trust him as much. Moreover, my thoughts differ from his; many suggestions I made during product design were hardly adopted, and I am not someone who is very assertive. Overall, the company is still under his control, and we can only offer opinions; whether to accept them is his choice. As for my colleague, I feel he is very obedient to the general manager, and when there is a disagreement between me and the general manager, he tends to side with the general manager, leaving me to silently endure much helplessness and grievance.
In summary, I did not handle things well towards the end before leaving. In the last month or two, because I wanted to withdraw but didn’t know how to bring it up, I ended up negatively impacting the company and others around me. However, during these two years of technical growth and over a year of social experience, I have gone through things that others my age have not experienced, enriching my social experience and also understanding some of my shortcomings, recognizing things I need to be wary of in the future. Currently, I have decided to follow my own plan.
I have consulted some classmates and friends regarding Linux. Generally, when it comes to drivers, most of the time, it involves porting others’ drivers and making some modifications. In contrast, application development is not as tedious. Currently, the Android industry is developing rapidly, and I have no firm views on whether I will work on Android in the future; for now, I will focus on mastering Linux first. Additionally, I tend to be the type who feels uncomfortable if I don’t deeply understand something, so I am currently studying the book Understanding the Linux Kernel. I haven’t done much hands-on practice with instructional videos, and I have only practiced sporadically before, so I only know how to use it but not the deeper principles. In the past, I saw a great expert say he resigned for six months to learn Linux, initially starting with kernel-related topics. Regarding the learning methods for Linux, I hope seniors can provide more advice; I personally believe learning methods vary from person to person.
Finally, I feel that the start of my career has been poor, and in terms of technology, I am still lacking compared to capable individuals. Many things I haven’t dealt with due to work limitations, and I feel I have wasted a lot of time, which has also affected my wife and worried my family. Compared to my peers, I feel quite miserable, and the pressure is considerable. The time left for me is also limited. In short, I believe things will get better.
My current insights are:
1. Starting a business is not easy;
2. Sometimes, you can’t overthink; you need to be decisive, and critical issues require calm reflection without being clouded by certain factors;
3. Be practical and steady;
4. Finally, your destiny is in your own hands; don’t place too much hope and fantasy on others.
So how are the salaries for embedded Linux and microcontrollers?
First, let’s talk about the standard definition of embedded systems—
“Devices used to control, monitor, or assist in operating machines and equipment.”
From this definition, it is actually quite broad, encompassing microcontrollers, PLCs, industrial control computers, and many other items that fall under the embedded category.
However, domestic education generally categorizes programmable control chips based on their functionality, with more powerful ones classified as embedded systems, especially processors or FPGAs, DSPs, CPLDs suitable for running lightweight systems like WINCE, Android, etc. Chips with poor efficiency that primarily run bare-metal specific programs and have lower applications are classified as microcontrollers. Regardless of the level of microcontroller, as long as it enhances stability and is designed for industrial environments, using statement tables and graphical programming methods to edit the logic of IO control systems is classified as PLC.
From a salary perspective, assuming the questioner does not pursue further education, I recommend prioritizing the following sequence:
1. Embedded (ARM + Linux): Can interface with industrial robots, IoT, high-end 3C product design, but you need to catch up on signal processing knowledge; it doesn’t have to be profound but you should understand it. Salary levels depend on the choice of company and industry characteristics, but they are generally better than 3 and 4.
2. Embedded (FPGA, CPLD, etc. integrated circuit design): This path is primarily about signal processing, requiring a solid foundation in mathematics, signals, and analog electronic theory. Generally, the starting point for successfully working in this area is a master’s degree, but if you are interested and capable, it is possible for undergraduates to excel here. Theoretically, salary is the primary consideration, but the work difficulty is also significant.
3. Microcontroller: Examples of related products include rice cookers, soymilk makers, and other home appliances with low levels of intelligence. The market is highly homogeneous, with many capable individuals, leading to fierce competition and low product profits, resulting in relatively low salaries and limited future salary increases. However, it is still slightly better than PLC.
4. PLC: Unfortunately, PLC is the least recommended direction. People working with PLCs typically work at small automation companies or the equipment departments of large companies, and overtime is common. Salaries are not high because even those with a vocational school level can compete for your job; the technical added value is currently very low, and there is little room for advancement.
——
Some people disagree with this:
@Jiangnan Yitiao Fish
The claim about PLC is a bit exaggerated. As for salary… several classmates have started small automation companies, and they have houses and cars; some even drive luxury cars and live in large houses.
The equipment departments of large companies, such as Chery and Guangben, are all equipment departments, but their salaries are not even close to each other. Large automation companies, whether private, state-owned, or listed, have significant differences in salary.
As for technology… do you really think PLC just means writing a couple of programs to get the motor running? Ford, GM, Toyota, and others have strict standards for their production equipment, from design to programming, simulation, and component selection, all must be done according to requirements. The most challenging part is that these standards are all written in English; can an average vocational school student grasp them?
Every industry has its high and low ends; a roadside stall is also a restaurant, and a Michelin restaurant is also a restaurant; can they be equated?
So should one transition from microcontrollers to embedded Linux?
Famous embedded engineer Huo Ge says: (from the career path of embedded veterans)
Although Huo Ge is currently engaged in embedded development in Linux/Android, he has about five years of experience with microcontrollers and RTOS during his studies. He has also received offers for microcontroller STM32 development during interviews, so today he shares some views on whether to transition from microcontrollers to embedded Linux.
1. Are you really decided to transition to embedded Linux?
Whether to transition from microcontrollers to embedded Linux is a serious decision that affects career development. Huo Ge cannot make the decision for you but can help you list the pros and cons. You need to make the most advantageous decision based on your various circumstances (for instance, are there many Linux embedded-related positions in your city? Are you willing to leave home to develop in cities like Beijing, Shanghai, or Shenzhen, etc.?). Huo Ge’s opinion is not that Linux embedded is absolutely better than microcontroller development; it is just based on his experiences and offers some perspectives.
1. The biggest disadvantage of microcontroller development compared to Linux embedded is that the average salary for entry-level positions is relatively low. I think this is the primary reason most microcontroller engineers want to transition to embedded Linux. The technology itself has its advantages and disadvantages, but for entry-level jobs in the same city, the salary for microcontrollers (including RTOS) is 30% to 50% lower than that for embedded Linux. Perhaps many people will compare the high salaries of certain microcontroller positions (like those of Huo Ge from Wildfire, Zhou Lijing, etc.) or some company executives’ salaries with those of engineers working in embedded Linux, proving that microcontrollers can also earn high income. However, they are making the mistake of comparing a top-quality horse with a mediocre one; Huo Ge believes that this type of comparison is very unrealistic. Currently, Huo Ge has found that in Shenzhen’s entry-level job market, the starting salary for microcontroller (including RTOS) development is around 6K-7K, with 15K being considered high salary for most. It is challenging to break through 20K. There are some microcontroller offers above 20K, but they are rare, usually only for well-known companies or prestigious backgrounds, and the average person cannot obtain them. In contrast, for embedded Linux/Android, a starting salary of 12K is quite normal, and generally, after two years of work, it is common to exceed 15K; breaking 20K or even 25K after 3-5 years is also common, and for those with over five years of experience in top-tier companies (like Huawei, OPPO, VIVO, etc.), salaries can reach 30K. If you become a module owner expert in a mobile phone company, breaking 40K is also possible, but it becomes a bit difficult beyond that. Overall, among entry-level workers of the same caliber, embedded Linux salaries are significantly higher than those for microcontroller development. Microcontroller salaries hit a bottleneck at 15K, while breaking 20K in embedded Linux is not difficult, with the bottleneck appearing above 25K.
2. Are there many embedded Linux positions in your city? I think this is another major issue affecting your decision. Most people learn embedded Linux technology primarily to engage in related work rather than for personal growth. However, according to Huo Ge’s statistics, while the average salary for embedded Linux is generally higher than that for microcontrollers, there are not as many job openings for embedded Linux. Shenzhen appears to have the most opportunities for embedded Linux, but microcontroller opportunities seem more abundant. In Shenzhen, the ratio of microcontroller to Linux positions is about 6:4. From the perspective of embedded Linux job availability in various cities, it ranks as follows: Shenzhen > Shanghai > Beijing > Chengdu = Hangzhou = Suzhou > Dongguan (with Huawei’s support) >= Zhuhai >= Nanjing = Guangzhou = Wuhan = Xi’an = Fuzhou = Xiamen > Foshan = Changsha = Tianjin = Hefei > Others. I have little knowledge of embedded Linux development positions in other cities. Therefore, if you are considering a career transition, the first thing to consider is whether you are willing to leave your hometown for the above cities. Otherwise, even if you learn impressive Linux skills, you may find it difficult to find relevant positions locally and may have to continue working in microcontroller development.
3. Although microcontrollers have lower salaries, there are more job opportunities and they are relatively friendly to older job seekers. This point is not contradictory; many small companies in various industries need microcontrollers (of course, traditional home appliance giants like Gree and Midea also hire, but few emerging high-tech companies like Huawei and SenseTime recruit microcontroller engineers). There are diverse businesses, and therefore more positions are available. However, generally, small factories may not have enough funds to offer high salaries, coupled with the low threshold for microcontroller development (not considering product stability, EMC, etc., experienced workers naturally understand these concepts, only referring to the training threshold for learning to use microcontrollers), which results in a relatively short training period (a sophomore student can learn it in a summer). This leads to a considerable number of mid-to-low-level workers, which lowers the average salary. This is similar to Foxconn, which hires many but complains about the lack of skilled workers. The owners are unwilling to raise salaries to control costs, creating a long-standing contradiction between the lack of skilled workers and low salaries. However, for older job seekers, since there are indeed many microcontroller positions, many small factories find it challenging to hire excellent talent at a high cost. In small factories, there is no HR involved in human resource planning, and age hierarchy is not strictly enforced. Therefore, older job seekers can find jobs as long as they do not demand high salaries. Compared to large factories focused on Linux, the microcontroller industry is more lenient on age issues (perhaps because microcontrollers have been around for a long time, there are many older practitioners).
4. There are also some high-paying positions in microcontrollers. In the eyes of microcontroller engineers, 20K or more is considered high salary. Based on this standard, Huo Ge has seen some high-paying positions, but they come with specific requirements. A company that makes smart locks using STM32 once offered Huo Ge 20K, mainly because they wanted technical personnel with backgrounds from prestigious universities, which would make communication easier. Therefore, they could offer 20K. Another well-known unicorn startup offered 25K for a microcontroller position, but the prerequisite was that the candidate must be able to develop microcontrollers in a Linux environment, and the interview difficulty was relatively high. Initially, they were not willing to offer such a high salary, but after Huo Ge kept them waiting for a week, pretending to have received a similar offer from Huawei, they finally agreed to offer 25K. Huo Ge has also learned of senior microcontroller engineers earning 800K annually (who master certain industry-specific certification standards). However, overall, high-paying offers for microcontrollers are indeed challenging to obtain, and even when they are, it is often not solely due to your technical skills or debugging abilities but rather due to your background, education, and other offers that help raise the salary. These special qualifications and educational backgrounds cannot simply be acquired through hard work and study. If you could easily acquire a skill just by putting in time, it would not be a skill that has significant barriers to entry.
Having outlined these points, whether to transition from microcontroller development to embedded Linux, I believe you should be able to make a decision.
2. What are the similarities and differences between microcontrollers and embedded Linux development?
1. The advantages retained from transitioning from microcontrollers to embedded Linux primarily lie in proficient C programming skills and rich debugging experience with software and hardware interfaces. Since the Linux kernel is written in C, and most Linux applications are also in C, those with microcontroller development experience should not have issues with C programming. Thus, during the transition, there is no need to consider switching languages. However, if you have not systematically studied data structures (Huo Ge believes that understanding data structures is essential for mastering C, even for microcontroller developers), you may need to supplement that knowledge. Additionally, having experience with real-time operating systems like uCOS or FreeRTOS is even better, as it will make you less intimidated when reading large-scale C code. However, understanding the uCOS kernel does not mean you can immediately grasp the Linux kernel, as the Linux kernel is significantly more complex and has a different design philosophy.
2. Transitioning from microcontrollers to Linux embedded requires familiarization with a distinctly different development environment. For most microcontroller engineers, the primary development environment is IDE on Windows (some companies may already be using Linux for microcontroller development). However, many of you may not have much exposure to Linux systems like Ubuntu, so the first hurdle you must overcome is not the Linux kernel source code but how to use a Linux system like Ubuntu. In Debian, Ubuntu, CentOS, and various Linux systems, software development is primarily done via command line operations, not through mouse clicks in a graphical interface. Moreover, applications in Linux systems are not as integrated as in Windows IDEs, where you can simply click to use them. In Linux, many Makefile compilation scripts and services like Samba, SSH Server, etc., need to be configured according to your requirements. You will need to assemble and use various components, which may involve numerous environmental or compilation issues (open source software can be messy). Therefore, for those new to Linux, even if you have rich C experience, getting accustomed to it can be time-consuming, and you must overcome psychological barriers. The Linux development environment is like a rebellious stallion; you must tame it to unleash its value, while the Windows development environment is more like a docile horse.
3. The level of control over code in embedded Linux development is significantly lower than in microcontroller development, requiring adaptation to working in an environment of low control and insecurity. In microcontroller development, including RTOS, the code volume typically does not exceed tens of thousands of lines. Even if you haven’t read every line, you can usually control every module and have a good idea of where bugs might be. In embedded Linux development, the Linux kernel alone consists of millions or even tens of millions of lines of code, not to mention various unfamiliar application libraries. This means that most of the code is beyond your control. The embedded Linux development model involves developing drivers or applications in a context where you do not develop or control most of the code. You will often need to search for information and ask others about unfamiliar functions. This development model can place you in a state of insecurity, as many functions you use may not have known implementation details, and you may only have a superficial understanding of their mechanisms. Developing in such an environment necessitates strong search, communication, and teamwork skills, as you can no longer control everything as you could in microcontroller development. This insecurity is one of the most significant adjustments microcontroller engineers must make when transitioning to embedded Linux development.
4. Embedded Linux development requires a broad perspective; do not get lost in the jungle of details and lose sight of direction and exit. Many microcontroller engineers have a habit of focusing on the working principles of every register, the logic of every function, and scrutinizing every if-else statement when programming. This approach can be very time-consuming when learning Linux embedded systems and can lead to inefficiency. While attention to detail is good, when the system becomes large, overly detail-oriented individuals often struggle to manage it. I have seen many beginners get bogged down in every register and the writing of every linker script, treating the startup process of one chip as the only truth for all chips, trying to apply it universally. They fail to realize that many things are merely habitual practices established by people, and each company’s chips have their characteristics; the processes are fixed, but people are flexible. Mastering the big picture allows you to quickly familiarize yourself with the entire system’s knowledge, and many habitual details will naturally become clear. When you encounter specific detail problems hindering your progress, you can then try to address them. Mastery does not imply knowing the meaning of every line of code or register; instead, it means you can make the entire system operate according to your intentions.
3. What basic knowledge is needed when transitioning from microcontrollers to embedded Linux?
Having talked so much, we now get to the core content: what do you need to learn to transition from microcontrollers to Linux embedded? If I don’t include this section, I fear you might make the decision to switch careers and immediately pick up a book on Linux kernel architecture and implementation, thinking it is just like learning an RTOS like uCOS, only to find it confusing. In fact, when I first learned Linux embedded, I made similar mistakes, which is why I have summarized some experiences and lessons.
1. You need to spend some time familiarizing yourself with how to program and develop using Linux systems. I believe many of you grew up using Windows computers and probably had little exposure to Linux systems like Ubuntu before studying computer programming. This system does not respond like Windows with mouse clicks; it requires various command line operations. Moreover, the system has various services and application tools that you need to configure according to your needs. Therefore, learning embedded Linux development is not about rushing into the depths of Linux kernel code but rather about first mastering how to use the Linux system. You can refer to books like Bird’s Linux Private Kitchen to learn how to install and use the Linux system and become familiar with command line usage. However, Huo Ge believes that learning should be goal-oriented; if you try to learn every command in Bird’s Linux Private Kitchen page by page, it will become tedious after a few days. Thus, Huo Ge recommends that those with microcontroller development experience set their first goal as establishing a cross-compilation environment for your microcontroller development board on the Linux system and compiling a bare-metal LED lighting program (without needing to run the Linux kernel) and burning it using the tools provided by the board manufacturer. This task is not difficult, as many articles online explain how to cross-compile microcontroller programs on Linux, especially for the STM32 series. You can refer to others’ articles to accomplish this, 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 articles), and other Linux programming environment knowledge, thus beginning 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 aiming to develop microcontroller programs on the Linux system, but rather to work on Linux drivers or application development. After completing the initial learning step, do not get too bogged down in the details of how to write compilation and linking scripts; instead, focus your efforts on Linux system development. To learn embedded Linux system development, you first need to know how a Linux system operates, how to set up a Linux system environment on a development board. This involves bootrom, bootloader, uboot, dts, Linux kernel, cmdline, rootfs, and a series of components, as well as various boot methods like nand and nor. Knowing how an embedded Linux system works will allow you to modify and add your drivers and applications. There are many practical aspects to this, and you may need video materials to guide you through the process for a quick start. Huo Ge previously watched Teacher Wei Dongshan’s embedded Linux videos, which have several episodes, some of which are free to preview and others paid; you can contact the seller on X treasure for more information. Huo Ge will not post advertisement links here. Additionally, there are other videos that Huo Ge has not watched, so he will not casually recommend them. In learning embedded Linux, theoretical knowledge should be gradually absorbed through reading, while practical knowledge should be acquired through video materials and hands-on operations, creating a cycle of theory and practice.
3. You can start trying out some simple Linux application and driver development. After completing the previous two steps, I believe you will have a certain level of professional understanding of embedded Linux development. Huo Ge prefers the learning style of learning by doing, with 60% practice and 40% theory. This is because many system environment-related aspects of embedded Linux are not as strict as theoretical formulas found in books. It is difficult to find patterns just through reading, and in the Linux kernel, there is a whole set of jargon from the GNU world (you can search what GNU means). Technical experts who write books on Linux kernel and driver development cannot possibly explain all the jargon. Therefore, without prior experience in using and developing, directly opening books like Advanced Programming in the UNIX Environment and Linux Device Drivers can leave beginners confused. Huo Ge suggests 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. At this stage, you don’t need to worry about how the initialization and registration framework functions in the Linux driver you are calling work. Through the process of practice, you will become familiar with the entire code execution environment and the various terminologies used in Linux development (system calls, vfs, etc.). This is also a way to gain positive feedback from your learning, enhancing your sense of achievement and confidence in learning. In fact, Linux driver development itself is not difficult (the difficulty level is not higher than the formulas in your complex analysis textbook), and it is not mysterious; it just has a whole set of jargon that can easily confuse beginners. With a normal IQ, an average undergraduate student should be able to master it.
4. You need to supplement some theoretical knowledge of computer science. According to Huo Ge’s understanding, most microcontroller engineers come from electronics, communications, automation, or mechanical engineering backgrounds, and few are from computer science. These students often lack basic theoretical knowledge in computer science, such as data structures, operating systems, computer organization principles, computer networks, algorithms, and the basics of compilation and linking. Supplementing theoretical knowledge is a long-term process (which may take 2-3 years). You do not need to wait until you have completed all the theoretical knowledge before looking for a job; you can supplement your foundational knowledge while interviewing and job hunting, testing your fundamentals. This foundational knowledge not only enhances your technical skills but also helps you pass written tests and interviews, determining whether you can break through the 20K salary mark in first-tier cities. With a solid foundation in computer science and some experience in Linux driver development, it is necessary to study the Linux kernel, but beginners do not need to rush into the Linux kernel source code. The kernel is quite extensive and profound, requiring time to read books and code gradually; it cannot be learned quickly. However, having a foundation in the Linux kernel can improve your salary competitiveness.
4. Advice for career changers with work experience.
1. For career changers with jobs, your advantage is having a stable job and income, while your disadvantage is the 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, not too proud or anxious, and learn while searching for a better job. Of course, those with jobs do not have much time flexibility. If the new knowledge you want to learn is not directly related to your current job, Huo Ge suggests choosing a job with less overtime, allowing you to free up time after work to learn new embedded Linux knowledge. Those with jobs can use their savings to buy some high-quality paid videos to accelerate their learning and save valuable time; this is also a way to exchange money for time. Generally, there is no need to be an expert before looking for a job; being in 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; business knowledge related to audio and video, communication protocols, etc., can be supplemented after securing a relevant job.
2. How can someone with only microcontroller experience and no Linux development experience find a job in embedded Linux development through social recruitment? This is a headache for job seekers who are concerned about their relevant work background. Huo Ge has the following suggestions:
First, check if the company has Linux-related departments and development plans, and actively try to transfer internally.
Second, see if you can suggest to the technical manager that they migrate the microcontroller development environment to Linux systems.
Third, you can try interviewing companies that develop microcontrollers in a Linux environment. After the interview, ask the interviewer if they develop microcontrollers in a Linux environment. If so, you can first join a company that uses Linux to develop microcontrollers and continue working with microcontrollers while familiarizing yourself with Linux.
Fourth, try applying for positions related to bootloaders or firmware development in companies that genuinely develop Linux systems. Bootloaders and firmware code related to storage controllers, power management, and other functions have many similarities with microcontroller bare-metal RTOS development. This will ensure that you can contribute in your new job rather than being solely a learner.
Fifth, try interviewing truly Linux companies with high turnover and attrition rates. Such companies can be described with one word: “short-staffed.” Previously, Huo Ge worked at a certain IC manufacturer in Zhuhai, where the number of relevant practitioners was low, many fresh graduates were unwilling to develop in small cities, and the company had poor performance in recent years, leading to a high turnover rate. Consequently, they relaxed their hiring standards and were willing to train job seekers with microcontroller experience but no Linux experience. Of course, Huo Ge is currently in a well-known large factory in Shenzhen, where the practitioner population is large, and the company’s brand and compensation are competitive, making competition fierce. Although they claim to be short-staffed (actually, they are too picky), they generally do not offer opportunities to job seekers without Linux experience.
Finally, during the process of learning embedded Linux, it is best to document the problems you encounter and the code you write in a technical blog or on GitHub, linking it in your resume. This is also a way to prove to interviewers that you have a certain understanding of embedded Linux. After reviewing your blog and GitHub, interviewers can better understand your technical level and decide whether to give you an opportunity.
5. Advice for students transitioning to a new field.
For students, you have more freedom in terms of time but lack money and do not have a guaranteed job.
Of course, time is like toilet paper; it seems abundant but can run out quickly. Therefore, even with ample time, you should plan well and try to learn as much as possible.
Since students lack money, Huo Ge does not recommend spending several thousand on offline embedded training. In reality, the training content is mostly entry-level knowledge, and the quality may not even compare to the affordable Wei Dongshan’s embedded Linux videos. Moreover, video tutorials may offer more flexibility in terms of timing than training.
Students have the advantage of not having industry-related experience during campus recruitment; they do not assess your industry knowledge but focus more on your foundational computer knowledge (Huo Ge even received an IC factory Linux offer based on his scores in operating systems, C language, and data structures, despite having no Linux development experience. Of course, he spent half a year after campus recruitment buying Wei Dongshan’s paid videos to fill in relevant knowledge). Thus, students should use their precious time to solidify the foundational knowledge mentioned in point 4, so that after starting work, they can focus on learning business knowledge and quickly advance in their careers without having to rebuild their foundations.
Additionally, students may participate in various microcontroller and embedded competitions, potentially winning many awards and receiving praise from teachers and classmates. However, remember to stay humble and not feel self-important just because you have mastered a couple of technologies compared to ordinary students (your competitors in interviews are not those who lack technical skills). Don’t let a few awards lead you to neglect learning foundational concepts such as time complexity, linked lists, stacks, and MMU virtual address space.
Finally, for students from other majors considering transitioning to embedded, we have specifically addressed this topic to assist those interested in this field!
Those involved may be confused, but those observing can provide clarity; regarding transitioning careers, let’s hear what others think:
Transitioning from mechanical to embedded, I don’t see it as a career change but rather an expansion of one’s professional field. After all, embedded software is not purely theoretical; most of its functionality is implemented through mechanical design. For instance, when designing a robot, what knowledge do you think is needed? Is mechanical design and embedded software enough? Far from it. Learning embedded software design does not mean giving up mechanical design.
Having this idea is great. Purely mechanical work is not optimal; the trend will definitely be towards interdisciplinary skills.
From a personal development standpoint, the overall salary in the software industry (embedded/communication/internet) is better than that in traditional mechanical industries. If you have the will and determination to learn actively and improve your living standards, switching industries is definitely an option.
Embedded software development will be quite popular in the future, and its application range is broad. However, I do not recommend completely abandoning your original field; it’s best to find some intersection points. This way, your career fluctuations will be smaller.
I studied mechanical engineering, but I also have a strong interest in electronics and software. I learned about microcontrollers and circuit design, so I have some insights in this area. For someone purely from a mechanical background, transitioning to electronics or software requires significant change, and it’s best to have someone guide you. Software requires deep learning, so if you want to develop in this area, you will need to learn a lot.
If you feel that your expertise in mechanical design has not yet been fully realized, I suggest not changing careers. If you have the ability but find the work challenging, don’t give up. Every industry has its difficulties; the question is how long you can persist in the face of challenges. After comprehensive analysis, if you feel your abilities cannot sustain you, it is advisable to switch without hesitation. Of course, transitioning to a new field will also present difficulties.
Of course, the above advice is for reference only. If you have truly made up your mind to become an embedded engineer, you can consider the following suggestions:
1. Embedded systems involve a lot of foundational knowledge.
You should know the basic syntax of C language, what structures and unions are, and the differences between them. There is no need to memorize everything; in practice, these concepts are rarely used.
You should also understand C++, including what classes are, how to define them, inheritance, and interfaces, as well as the basic syntax.
Knowledge of operating system principles is also essential, such as understanding time slices and task scheduling.
Additionally, you should be familiar with basic Linux commands (you must know how to use the vi editor because you can only modify files in the terminal using it). Many of us have become accustomed to using a mouse and rarely use commands; we need to change this habit when learning embedded Linux. Using commands is more efficient and powerful than graphical interfaces. In fact, the operations we perform via graphical interfaces are ultimately translated into commands sent to the hardware.
You should also understand Linux file system management, including which directories store what, their uses, and file permission management.
Some knowledge of shell programming is also necessary; I recommend a tutorial by Zhou Zhaojian on shell programming, which is comprehensive and only requires seven or eight lectures for a complete understanding. Beginners can focus on the first four lectures.
2. Don’t expect to understand everything in one read; don’t memorize blindly.
If you don’t understand something, it’s okay; as long as you know where to find the information later, you’ll remember it after encountering it multiple times. If you encounter something infrequently, forgetting it is fine. Also, don’t jump directly into reading Linux kernel source code; tackling concepts that are too complex without understanding them can demotivate beginners. It’s better to gradually progress, starting with simple tasks like making an LED light up, then moving on to serial communication, and eventually tackling hardware encoding and decoding.
3. You can choose not to accept training, but you cannot skip buying a development board.
If you want to learn embedded systems, you must buy a learning board. Nowadays, development boards are quite affordable, alleviating much of the financial burden on beginners. Watching videos and reading books is not as effective as hands-on practice. Even seemingly simple tasks can present many challenges when you try to do them yourself. When I first wrote the LED driver, I was excited to try it, and while there were existing codes online, I encountered numerous problems and spent a whole day just to light up the LED. Therefore, don’t have high expectations without practical experience.
Regarding training, many institutions offer good courses, and the instructors are often excellent. However, there is a common issue: the content is too concentrated, and students have limited hands-on opportunities. I remember our company hired someone who had trained for six months at a certain training institution in Beijing; he spent over ten thousand yuan but didn’t seem to have gained much. When I asked what he learned, it turned out to be just the foundational knowledge I mentioned earlier. Many things remain unknown to him, and he struggled for two days to write a simple hello world module driver. Training is not inherently bad, but in my opinion, the effectiveness is not particularly high. Remember: only the things you have done yourself are truly yours.
4. Don’t aim too high; be practical and grounded.
For beginners, here’s a small piece of advice: when we get our development board, we feel excited and have many ideas. We want to implement all of them but may not know where to start. Thus, we might post in forums asking, “How do I achieve this? Could someone please explain in detail? I’m begging!” Then we wait for responses and complain when there are none. Having ideas is good, but before realizing them, you need to understand the relevant knowledge. If you don’t understand something, Google it (it’s better not to use Baidu, as it’s not very effective) to learn a bit, which will give you a rough idea of how to proceed. If you encounter problems afterward, then you can ask for help. This way, you’ll show that you have some knowledge and can ask informed questions. For example, if you don’t understand what a serial port is, asking how to implement serial communication is not helpful. If someone gives you code, you won’t understand what it means.
5. Read more code and write more code.
Seeing more and practicing more leads to skill improvement. Read code to understand its meaning. Also, practice writing code regularly.