Follow and star our official account, to access exciting content

I started working with the 51 MCU during my undergraduate studies and faced challenges in electronic competitions.

During my master’s program, I also used MSP430 to develop some embedded products in collaboration with industry and academia, which were practically implemented in small batches.

Although I had some exposure to Linux embedded development during my master’s, reflecting on that time, PLC + configuration and MSP430 MCU were indeed my strengths (the FPGA + Verilog project I worked on for my graduation thesis was not impressive; at that time, I naively attempted to interview for FPGA positions, and the outcome was predictable).

After joining Huawei, although I worked with Linux and VxWorks operating systems, I actually dealt more with MCU and application programming in the Linux user space. Those who have experienced larger companies know that a screw is just a screw; you can only see the trees, not the forest. However, during my years at Huawei, my coding abilities significantly improved.

When I left Huawei, my thoughts were somewhat similar to the questioner; every day I faced the same chips, always working on the modules I was most familiar with, and the phenomenon of reinventing the wheel was severe. I wanted to learn new skill stacks but had no time or energy.

Finally, I received an offer for Linux embedded development from a communication chip supplier, thinking I had some foundation in Linux embedded, so I happily jumped into this chip giant’s development of communication protocol stacks.

Ideals are plentiful, but reality is stark. It can be said that the development of embedded Linux and MCU has similarities and connections, but the differences are also significant. However, for the answerer, there was no turning back, and I recognized the advantages of Linux in terms of technical barriers. What to do? I could only muster the determination I had when I first joined Huawei and tackled C programming head-on.

Back then, there were no knowledge Q&A platforms like Zhihu, so I consulted old employees of the new company and classmates who graduated with me and were engaged in Linux embedded development for their experiences and learning paths. After receiving their enthusiastic replies and guidance, I embarked on another round of tackling Linux embedded technology.

Embedded Linux development can be broadly categorized into BSP and application development.

To meet the challenges of my new job, I first chose to review and advance my skills in embedded Linux application development. Later, when I left this company to start my own business, I also tackled embedded Linux BSP due to cost issues; for now, let’s focus on applications.

1. Shell, VIM, and Makefile

Many friends might ask if it’s necessary to learn these two tools. My advice is that it is very necessary. If you don’t understand basic shell commands, how can you manipulate the Linux file system?

If you don’t use VIM well, while Windows folders can be mapped to Linux systems, character encoding issues in Windows often cause inexplicable problems in Linux. Shouldn’t you learn VIM text editing?

As for Makefile, friends working with MCU and DSP might be unfamiliar with it. In MCU and DSP, the accompanying coding download software takes care of Makefile for you; you only need to configure it in the UI to automatically generate the compilation file chain. For example, in Keil, you tell Keil where the compilation files are and what the macro definitions are. However, back then, when I compiled Linux, I had to manually tell the embedded compiler in the Makefile what files to compile and what files to generate:

Additionally, learning to set up a cross-compilation environment is a necessary skill for embedded Linux developers. This isn’t too technical; understanding the basic principles can be done in half an hour.

For the above, I don’t recommend dedicating large blocks of time for study and practice. In your spare time, install a virtual machine environment with a Linux system, buy a basic Shell tutorial, and tinker with it for a few days to grasp the basics of Shell and VIM.

As for Makefile, I recommend searching online for the old document “Learn Makefile with Me.”

2. Common Linux APIs

Since the questioner is transitioning from MCU, I assume they are proficient in C language. If they have experience with RTOS, understanding Linux will be much quicker.

If there is no RTOS experience, that’s okay. Starting from scratch might actually be less influenced by previous knowledge and understanding.

In fact, the commonly used Linux application-level coding primarily involves a few libraries and APIs: multithreading, multiprocessing, blocking and non-blocking theoretical mutual exclusion mechanisms: read-write locks, spin locks, and other thread communication mechanisms, as well as network communication sockets.

Follow a book, read through it, practice while working, and use the virtual machine + Linux system you set up for coding verification. With a solid foundation, it’s quite easy to get started.

If you don’t have a concept or foundation in RTOS, there’s really no need to worry; understanding MCU RTOS will only help you learn Linux threads and processes faster. If you don’t understand it, you’ll just learn at a slower pace. Here I recommend a textbook I’ve used; it might not be highly praised, but I found it sufficient:

As for whether to learn UI development, it depends on the questioner’s work situation.

3. Debugging Techniques

After patiently reviewing the knowledge from the previous two stages and combining it with work and coding practice in my virtual machine environment, a project can be tackled alongside learning, and the questioner can definitely grasp the essentials of embedded Linux.

However, every program will inevitably have bugs. The IDE used in MCU can provide us with some debugging information, breakpoints, and other means. In Linux, we can only rely on GDB, this powerful tool, to help us find traces of bugs in the Linux world.

There are many resources online for learning GDB. The strategy remains: learn, practice, and summarize. Over time, with enough accumulation, you will naturally become proficient in GDB. I went through the phase of tough learning and gradually transitioned to Linux application development during projects. The code I wrote for the communication chip protocols might be used in your computers and mobile chipsets, haha.

This process, although arduous, is a joyful pursuit for those seeking technical advancement; learning new technologies and skills is always rewarding.

In fact, Linux BSP is another major aspect of embedded Linux development. During my later entrepreneurial endeavors, I also mastered the basic Linux BSP skill stack through persistent learning. Since today’s article is getting lengthy, I won’t elaborate further. If there are friends interested or in need, I can continue to write about how to expand from Linux application development to the Linux BSP development skill stack.

The above represents only my personal experiences and views, for reference only. Additionally, if there are inaccuracies or errors in the technical aspects mentioned, please feel free to criticize and correct.

Author: snowdream

Source: Zhihu

Finally

If you find this article good,share it, it’s also our motivation to continue updating.

5T Resource Giveaway!Including but not limited to:C/C++, Linux, Python, Java, PHP, Artificial Intelligence, PCB, FPGA, DSP, LabVIEW, MCU, etc.!

Click the card below and reply “More Resources” to get free resources.