Detailed discussion on embedded C programming experience

Aguilera

Detailed discussion on embedded C programming experience [Copy link]

If a device program is perfectly libraryized, it means: 1. All engineers spend very little when porting or creating the device driver. 2. As the number of users increases, it has been tested and stabilized, becoming a well-deserved public code. 3. The external interface of the library (function name and parameter declaration) is unchanged. When all commonly used devices are libraryized, it brings another benefit. The time spent on porting, creating, modifying and maintaining the application layer will also be greatly reduced. The cross-platform seamless porting of the application layer is not a legend. When all the peripheral devices it relies on are libraryized on different platforms, the implementation of the application layer is like writing Java code. 4. The library means the security of the company's core code. The library code is only in the hands of core engineers, so it is not a problem even if the application layer program is lost. 5. Newcomers can get started with these library-based projects more quickly, because there are instructions in the library help documents, and they don’t have to care about the underlying details and can’t care about them, so they can focus on application development. 6. Provide secondary development to customers. You can give the hardware and peripheral driver libraries to customers for secondary development. 7. The libraryization of communication protocols will make communication system products safer, at least they will not be damaged by engineers who leave, such as RFID deduction and recharge. 8. ...... How about it? It makes the boss excited and the engineers have mixed feelings. Of course, some engineers will think that the library can help them get rid of the tedious underlying driver work and do higher-level work. To create a good library, there are several conditions: 1. Only .h files and .lib files are provided to customers. 2. There is no define in all .h files, and the compilation conditions are just a joke for .lib files. 3. There are no extern variables in all .h files. If there are, it means that the system can only create one such device. For example, if there is an extern variable for the buzzer driver, it means that the entire system only allows one buzzer. 4. Complete and detailed usage help documents. You can refer to the hlp document format of Keil. 5. A simple demo program using the .h file is provided for reference. 6. "Dynamic link" library code, in short, unused interface function codes will not be put into the final binary file by the linker. 7. Another point is to try to be platform-independent, it does not depend on any registers or other platform-related things. To achieve the above goals, the library usually has the following features 1. Structure pointers 2. A large number of callback function pointers. 3. Rich interfaces. 4. The .c file of the library source code will be split into more .c files according to the interface function, in order to minimize the code space during linking. There are also disadvantages of the library 1. It will slow down the device speed and consume several more layers of indirect addressing. But for 32-bit machines, the convenience it brings is still acceptable. 2. It will consume a relatively larger code space, but please believe me, for an entire medium and large system, it will reduce the amount of code, because there are a lot of repeated redundant codes in large systems. In my personal experience in this regard, the reduction is not ordinary, it is simply to an incredible degree. In the early 8-bit machines, the 51 platform could not actually implement a perfect library, at least it could not implement a cross-machine model underlying device driver library. In recent years, with the rise of 32-bit machines, libraries have gradually been favored by more and more engineers. The most fundamental reason for this is that the stack of the 51 architecture is statically compiled, the stack of local variables and parameter passing is also static, and the function cannot be reentered. Most 32-bit machines use the stack push method to pass parameters. Of course, the slow speed of 51 is also one of the important reasons. If you are familiar with object-oriented languages or Linux drivers, you probably understand what a good library looks like. The library is like a class in object-oriented programming. As for the code of the Linux underlying driver, it is the world of function pointers and structure pointers. The essence of C is in the pointer, which is perfectly interpreted in it. Of course, the cost of the library is also there 1. It will slow down the device speed a bit, and there are several more layers of address fetching consumption. But for 32-bit machines, the convenience it brings is still acceptable. 2. It will make the code consumption larger, but please believe me, for a medium or large system, it will reduce the code instead of increasing it, because there are a lot of repeated redundant codes in large systems.