5 Key Points to Remember in Embedded Programming

Aguilera

5 Key Points to Remember in Embedded Programming [Copy link]

     We have specially compiled the opinions of engineers with many years of experience in embedded programming, and summarized them into a note that can be instructive for embedded programming experience. Interested friends, come and have a look. The reason why these two things are difficult is that they have to be written in assembly or C-like, which is a relatively low-level thing. Interrupts include external interrupts and internal interrupts. External interrupts have two implementation modes, hardware interrupt mode and software interrupt mode. They are relatively simple and belong to the application level. In contrast, internal interrupts are much more complicated. Internal interrupts are mainly caused by restarts, bus errors, overflows, check errors, etc. Many software developers basically do not write corresponding interrupt service programs because it is too difficult and generally not used. But once it happens, it is a fatal error. Therefore, from the perspective of the robustness of the entire system, there must be a corresponding ISR. This is also recommended by Freescale experts. Therefore, let's talk about the issues that should be paid attention to in embedded programming. 1. Delay embedded programming often involves hardware operations, such as ADC, opening or closing a current source, which all take time. Therefore, when these instructions are issued, the desired results cannot be obtained by reading the register value immediately, and the reason cannot be found. Sometimes the required delay is relatively long, reaching the ms level. In general, the us level is enough, depending on the clock frequency of each chip, not just the bus clock frequency of the MCU. 2. Variables Generally speaking, if the scope and life cycle of a variable are very clear, relative variables should be defined, such as const, static, etc., so that it is not easy to make mistakes. It is not recommended to define all variables as global variables, which is more troublesome to manage. Once the program goes wrong, the destructiveness is also relatively large. The same is true for functions. Global variables and general functions must be declared, so that it is not easy to make mistakes when calling. In addition, some compilers will not report errors for undeclared functions, but will issue warnings of implicit type conversions when calling. I will not give examples here. In short, you must be especially careful about this. 3. Macro definition During the program writing process, macro definition should be used as much as possible for some specific numbers. This has the advantage of being more intuitive and convenient for future maintenance. Otherwise, after a long time, you will not remember what the number means. Macro definition does not bring any burden to the program because it has been completely replaced during compilation, so it can be used as widely as possible. It is worth mentioning that macro definition is not limited to the use of constants. It can define functions. Because it is a direct replacement, it avoids stacking and popping, which improves the efficiency of program execution, but at the same time increases the amount of code. Therefore, simpler functions are generally used. It also has a disadvantage that it does not check whether the parameter type is normal during the replacement process, thereby increasing security risks. The solution to this problem is to use an inline function called inline, which inherits the advantages of macro definition and makes up for its shortcomings. It is the best choice, but this belongs to the scope of C++ and has certain difficulties. I will not talk about it here. Friends who are interested can refer to relevant materials. 4. Floating-point operation Most low-end MCUs do not support floating-point operation, so they are rarely used in actual use. Therefore, in order to reduce costs, the floating-point operation module is generally removed. This brings a problem. What if floating-point operation is needed? Careful friends may find that even MCUs without floating-point operation can still use float or double data types for calculations during simulation debugging, and the results are very accurate. Why is this? This is because the compiler automatically calls the library function to achieve it, generally through an iterative method, so its execution efficiency is very slow. This method is not recommended, and the "fixed-point" method is usually used to solve this problem. For example, for a 32-bit data, it can be assumed that its lower 8 bits are decimal places, and then shift calculations are performed, similar to integer operations. This method is more complicated, but can be very accurate. Another method is to directly magnify 10 to the power of N for integer calculations, which can produce approximate values. Therefore, in order not to add unnecessary trouble, you should always try to avoid using floating-point operations, which can generally be avoided. 5. Watch dog Take triple watch dog as an example, watch dog1 checks the clock frequency, watch dog2 monitors a small section of code, it must be fed once in a relatively short time, generally required to be fed once between 250us and 650us, watch dog3 monitors a large section of code, and requires to be fed once in a relatively long time, generally within 100ms, and all three conditions must be met at the same time, which requires a very clear understanding of the code execution process, or it will cause the dog to feed an error and restart. What needs to be emphasized here is that the quality of the program in the programming process of single-chip embedded is often determined by details. Whether a program is written in detail and flexibility is proportional to the accumulated knowledge and actual practice. Although programming is a very boring and even tedious process, the joy after success can make everyone believe that the effort is worth it.