Wu Jianying’s Microcontroller Development Board Address
Shop:【Wu Jianying’s Shop】
Address:【https://item.taobao.com/item.htm?_u=ukgdp5a7629&id=524088004171】
Mastering three languages in embedded programming is considered unbeatable: Assembly, C, and C++. With limited energy, mastering the first two is sufficient. If not, one must be proficient in C; otherwise, one can only be a leader, haha. I’ve been in this industry for over a year and have some experiences to share, mainly to help beginners.The two most challenging parts of embedded programming are interrupts and memory management (MM). Some people may not feel this because, in most cases, chip manufacturers have already written the code for you. However, if you work for a chip manufacturer, you must write the configuration files yourself. These two areas are difficult because they require writing in Assembly or C-like languages, which are lower-level. Interrupts can be external or internal. External interrupts have two implementation modes: hardware interrupt mode and software interrupt mode, which are relatively simple and belong to the application layer. In contrast, internal interrupts are much more complex, mainly arising from situations like restarts, bus errors, overflows, and checksum errors. Many software developers do not write corresponding interrupt service routines (ISRs) because they are too difficult and generally not needed. However, when they occur, it results in a fatal error. Therefore, to ensure the robustness of the entire system, corresponding ISRs must be present, as advised by experts from Freescale. Due to my limited knowledge, I won’t elaborate further to avoid misleading everyone. Now, let’s discuss some issues to pay attention to in embedded programming.1. DelayEmbedded programming often involves hardware operations, such as ADC, turning on or off a current source, which all require time. Therefore, when we issue these commands and immediately read the register values, we cannot obtain the desired results, and we can’t identify the reason. Sometimes, the required delay can be quite long, reaching the millisecond level; generally, microsecond level is sufficient, depending on the clock frequency of each chip, not just the bus clock frequency of the MCU.2. VariablesGenerally speaking, if you are very clear about the scope and lifecycle of a variable, you should define it relatively, such as using const, static, etc. This reduces errors. It is not advisable to define all variables as global variables, as this complicates management. If an error occurs in the program, the damage can be significant. The same applies to functions; global variables and generic functions must be declared to avoid errors during calls. Some compilers do not report errors for undeclared functions, but they may issue warnings about implicit type conversions during the call. I won’t provide examples here, but this point should be taken particularly seriously.3. Macro DefinitionsDuring programming, specific numbers should be defined using macros as much as possible. This practice is beneficial because it makes maintenance easier later on; otherwise, after a long time, you may forget what a number represents. Macro definitions do not burden the program because they are replaced during compilation, so they can be used widely. It is worth mentioning that macro definitions are not limited to constants; they can also define functions. Since they are replaced directly, this avoids stack operations, improving execution efficiency, but it also increases code size. Therefore, simple functions are generally used. Another drawback is that the replacement process does not check whether the parameter types are correct, which increases security risks. A solution to this problem is to use inline functions, which inherit the advantages of macro definitions while compensating for their shortcomings, making them the best choice. However, this falls within the realm of C++ and has a certain level of difficulty, so I won’t elaborate further. Interested friends can refer to related materials.4. Floating Point OperationsMost low-end microcontrollers do not support floating-point operations, so they are rarely used in practice. To reduce costs, floating-point operation modules are generally removed, which brings a problem: what if floating-point operations are needed? Observant friends may notice that even microcontrollers without floating-point operations can still use float or double data types during simulation and debugging, and the results are quite accurate. Why is this? This is because the compiler automatically calls library functions to implement it, usually through iterative methods, which makes execution efficiency very slow, so this method is not recommended. The common approach is to use fixed-point methods to solve this problem. For example, with a 32-bit data type, you can assume its low 8 bits are decimal places and perform shift calculations, similar to integer operations. This method is more complex but can be very precise. Another method is to directly scale by 10 to the power of N for integer calculations to obtain an approximate value. Therefore, to avoid unnecessary trouble, floating-point operations should always be avoided whenever possible.5. WatchdogThe most advanced watchdog mechanism I have encountered is the triple watchdog. Watchdog 1 checks the clock frequency, watchdog 2 monitors a small segment of code that must be fed within a relatively short time, usually between 250us and 650us, and watchdog 3 monitors a large segment of code that must be fed within a longer time, generally within 100ms. All three conditions must be met simultaneously, which requires a clear understanding of the code execution process, or it will lead to watchdog errors and restarts!That’s all for now. Good programs are always determined by details. This must be accumulated over time. Programming can be a frustrating task, and there may occasionally be a little joy in success, but after all, it’s work, and there’s not much to say. In any case, focus on learning first; as the saying goes, skills should not be underestimated.
