Experience sharing of embedded C programming library creation

Library, this is a big killer! A device program is perfect for library.



It means:

1. All engineers spend very little on porting or creating the device driver.

2. As the number of users increases, it is put to the test, constantly stabilizing, and becomes a well-deserved public code.

3. The external interface of the library (function name and its parameter declaration) is unchanged. When all the common devices are implemented in the library, it brings another advantage. The time for porting, creating, modifying and maintaining the application layer will also be Drastically reduced. The cross-platform seamless migration of the application layer is not a legend. When all the peripheral devices it depends on are stored in different platforms, the implementation of the application layer is just 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 the core engineers, and the application layer programs are harmless even if they are lost.

5. Newcomers are quicker to get started with these library-based cases, and there is a description of the library help documentation. Secondly, they don't have to care about the underlying details and focus on application development.

6. Provided to the customer for secondary development, you can hand over the hardware and peripheral-driven libraries to the customer for secondary development.

7. The library of communication protocols will make the products of the communication system more secure, at least not by the engineers who leave the company, such as the recharge of RFID.

8. ......

How, it makes the boss heart, the engineers are mixed.

Of course, some engineers will think that the library can get him out of the cumbersome underlying driver work and carry out higher level work.

To create a library well, there are several conditions

1. Only .h files and .lib files are provided to customers.

2. There is no definition in all .h files, and the compilation condition is just a joke for the .lib file.

3. There are no extern variables in all .h files, and if so, this means that the system can only create one such device. For example, the buzzer drive, if the extern variable, means that only one buzzer is allowed in the entire system.

4. Complete and detailed use of the help documentation. See keil's hlp documentation format.

5. Simply use the demo program of the .h file for reference.

6. "Dynamic Link" library code, in short, the unused interface function code will not be retrieved by the linker in the final binary file.

7. Another point, as far as possible platform independence, it does not depend on any registers or other platform-related things.

To achieve the above objectives, the library will usually have the following characteristics

Structure pointer

2. A large number of callback function pointers.

3. Rich interface.

4. The .c file of the library source code will be split into more .c files according to the interface function, which minimizes the code space in order to achieve link.

The disadvantages of the library are also

1. It will make the device slower and consume a few more layers of indirect addressing. But for 32-bit machines, the convenience it brings is still acceptable.

2. It will make the code space consumption relatively larger, but believe me, for a whole medium and large system, it will make the amount of code not rise and fall, because there are a lot of redundant code in the big system. My personal experience in this area is not much more general, Jane has reached an incredible degree.

In the early 8-bit machines, the 51 platform did not really implement the perfect library, at least it could not implement a cross-machine underlying device driver library. With the rise of 32-bit machines in recent years, the library has gradually been favored by more and more engineers. The most essential reason for this is that the stack of the 51 architecture is statically compiled, the stack of local variables and arguments is also static, and the function cannot be reentered. Most 32-bit machines are the way to push the parameters. Of course, 51 slow speed 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 an object-oriented class. As for the underlying driver code of Linux, it is the world of function pointers and structure pointers. The essence of C is in the pointer, and it is perfectly interpreted in it.

Of course, the cost of the library is also

1. It will slow down the device and increase the consumption of several layers of address. But for 32-bit machines, the convenience it brings is still acceptable.

2. It will make the code consume a bit larger, but believe me, for a medium to large system, it will make the code not rise and fall because there are a lot of redundant code in the big system.