The first step is to look at embedded issues from the perspective of PC programming;
The second step is to learn to use embedded programming concepts;
The third step is to combine PC and embedded thinking and apply it to real projects.
Many friends transition from PC programming to embedded programming.
In China, very few embedded programmers have graduated from computer science; most come from automatic control or electronics-related majors.
These individuals have strong practical experience but lack theoretical knowledge; many computer science graduates end up working on online games or web applications that are independent of the operating system.
They are also reluctant to engage in the embedded industry, as this path is challenging. They possess strong theoretical knowledge but lack knowledge in circuits and other related areas, making it difficult to learn specific knowledge in embedded systems.
Although I have not conducted an industry survey, from my observations and the personnel I have recruited, engineers in the embedded industry either lack theoretical knowledge or practical experience.
It is rare to find individuals who possess both. The root cause lies in the issues with university education in China. I will not delve into this topic to avoid unnecessary arguments. Instead, I would like to present a few examples from my practice to draw attention to certain issues when working on embedded projects.
First Example: A colleague was developing a serial driver under uC/OS-II, and both the driver and interface encountered issues during testing. In the application, a communication program was developed, and the serial driver provided a function to query the number of characters in the driver buffer: GetRxBuffCharNum(). The higher-level application needed to receive a certain number of characters before it could parse the packet. The code written by a colleague can be represented in pseudocode as follows: 
This code checks if there are more than 30 characters in the current buffer and reads all characters from the buffer until the read is successful. The logic is clear, and the thought process is straightforward. However, this code does not work correctly. If it were on a PC, there would be no issues, and it would function normally. But in embedded systems, the outcome is uncertain. My colleague was frustrated and did not understand why. He came to me for help, and when I saw the code, I asked him how GetRxBuffCharNum() was implemented. Upon inspection: 
It is evident that there is a global critical section between interrupt_disable() and interrupt_enable() in the loop, ensuring the integrity of gRxBufCharNum. However, due to the frequent enabling and disabling of interrupts in the outer do { } while() loop, the time is very short. In reality, the CPU may not respond correctly to the UART interrupt. This is related to the baud rate, the size of the hardware buffer, and the CPU speed. The baud rate we are using is very high, approximately 3Mbps. The start and stop signals of the UART occupy one bit each. One byte requires 10 cycles. At a baud rate of 3Mbps, it takes about 3.3us to transmit one byte. How many CPU instructions can be executed in 3.3us? At 100MHz ARM, approximately 150 instructions can be executed. How long does it take to disable interrupts? Generally, disabling interrupts on ARM requires more than 4 instructions, and enabling them again requires more than 4 instructions. The code for receiving UART interrupts actually consists of more than 20 instructions. Therefore, this can lead to a bug where communication data is lost, manifesting as instability in the communication system. Modifying this code is actually quite simple; the easiest way is to change it from the higher level. That is: 
This allows the CPU time to execute the interrupt code, thus avoiding the frequent enabling and disabling of interrupts that can lead to delayed execution of interrupt code and subsequent data loss. In embedded systems, most RTOS applications do not include serial drivers. When designing code, there is often insufficient consideration of the integration between the code and the kernel, leading to deeper issues in the code. The reason RTOS is called RTOS is due to its rapid response to events; this rapid response relies on the CPU’s speed in responding to interrupts. Drivers in systems like Linux are highly integrated with the kernel and run in kernel mode. Although RTOS cannot replicate the structure of Linux, there are certain lessons to be learned. From the above example, it is clear that embedded developers need to have a thorough understanding of all aspects of the code.Second Example: A colleague was driving a 14094 serial-to-parallel chip. The serial signal was simulated using IO because there was no dedicated hardware. The colleague casually wrote a driver, but after debugging for 3 or 4 days, there were still issues. I couldn’t stand it anymore and went to take a look. The control of the parallel signal was sometimes normal and sometimes not. I reviewed the code, which can be summarized in pseudocode as: 
Data’s 8 bits are sent out sequentially from bit0 to bit7 on each high level. This should be normal. I couldn’t see where the problem was. After thinking carefully and checking the 14094 datasheet, I understood. It turns out that the 14094 requires the high level of the clock to last for 10ns, and the low level must also last for 10ns. This code only implemented the delay for the high level and did not implement the delay for the low level. If an interrupt occurs during the low level, this code would work. However, if the CPU does not execute during the low level, it will not work correctly. Hence, it works intermittently. Modifying it is also relatively simple: 
This works perfectly. However, this code is not easily portable because if the compiler optimizes it, it may eliminate these two delay loops. If they are lost, the requirement for the high and low levels to last for 10ns cannot be guaranteed, and it will not work correctly. Therefore, truly portable code should implement this loop as a nanosecond-level DelayNs(10); Like Linux, at power-up, first measure how long the nop instruction takes to execute and how many nop instructions are needed for 10ns. Executing a certain number of nop instructions is sufficient. Use compiler directives or special keywords to prevent the compiler from optimizing away the delay loop, such as in GCC: __volatile__ __asm__(“nop;\n”); From this example, it is clear that writing good code requires a lot of supporting knowledge. What do you think? Source: https://blog.csdn.net/coolbacon/article/details/6842921