Libraries are powerful tools!
If a device program is perfectly libraryed, it means:
1. All engineers spend minimal effort when porting or creating the device driver.
2. As the number of users increases, it becomes more stable through extensive testing, evolving into a well-deserved public code.
3. The external interface of the library (function names and their parameter declarations) remains unchanged. When all commonly used devices are libraryed, it brings another benefit: the time spent on porting, creating, and maintaining the application layer will drastically decrease. Seamless cross-platform porting of the application layer is not a myth; when all peripheral devices it relies on are libraryed across different platforms, implementing the application layer becomes as straightforward as writing Java code.
4. Libraries ensure the security of the company’s core code, as the library code is only in the hands of core engineers. Even if the application layer program is lost, it is not a problem.
5. Newcomers can get up to speed faster with library-based projects, as they have the library documentation for assistance and do not need to concern themselves with low-level details, allowing them to focus on application development.
6. Providing customers with secondary development, you can hand over the hardware and peripheral driver libraries to customers for further development.
7. Librarying communication protocols will make communication system products more secure, at least preventing damage from engineers who leave the company, such as in RFID payment systems.
8. ……
How about that? It excites the boss while leaving engineers with mixed feelings.
Of course, some engineers might think that libraries can free them from tedious low-level driver work, allowing them to engage in higher-level tasks.
To create a good library, the following conditions must be met
1. Only .h and .lib files are provided to customers.
2. There are no defines in any .h files; compilation conditions are merely a joke for .lib files.
3. There are no extern variables in any .h files; if there are, it means the system can only create one such device. For example, if there is an extern variable in a buzzer driver, it means the entire system only allows one buzzer.
4. Comprehensive and detailed usage documentation. Refer to the format of Keil’s hlp documentation.
5. A simple demo program using the .h file for reference.
6. “Dynamic linking” of library code, in simple terms, unused interface function code will not be included in the final binary by the linker.
7. Additionally, strive for platform independence; it should not depend on any registers or other platform-specific elements.
To achieve the above goals, libraries typically have the following characteristics
1. Structure pointers
2. A large number of callback function pointers.
3. Rich interfaces.
4. The library source .c files will be split into more .c files based on interface functions to minimize code space during linking.
There are also drawbacks to libraries
1. They may slow down device speed slightly due to additional layers of indirect addressing. However, for 32-bit machines, the convenience they provide is still acceptable.
2. They may consume relatively more code space, but trust me, for a medium to large system, it will actually reduce the code size because large systems often contain a lot of redundant code. In my personal experience, the reduction is not just significant; it reaches an unbelievable extent.
In the early days of 8-bit machines, it was not possible to implement a perfect library, at least not for cross-model low-level device driver libraries. In recent years, with the rise of 32-bit machines, libraries have gradually gained favor among more engineers. The fundamental reason lies in the fact that the stack of the 51 architecture is statically compiled, and local variables and parameter stacks are also static, making functions non-reentrant. Most 32-bit machines, on the other hand, use stack-based parameter passing. Of course, the slow speed of the 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. A library is like a class in object-oriented programming, while the code for Linux low-level drivers is a world of function pointers and structure pointers. The essence of C is in pointers, which is perfectly illustrated here.
Of course, there are costs associated with libraries
1. They may slow down device speed slightly due to additional layers of address fetching. However, for 32-bit machines, the convenience they provide is still acceptable.
2. They may increase code consumption, but trust me, for a medium to large system, it will actually reduce code size because large systems often contain a lot of redundant code.
1.If you love embedded systems, invest wholeheartedly; otherwise, give it up!
2.Avoid detours! Some tricks for debugging and porting embedded Linux device drivers
3.Book recommendations | 7 books suitable for programming beginners~
4.Will GPUs replace CPUs?
5. The era of artificial intelligence has arrived; a starting salary of 250,000 is still just a low price!
6.Why is software development so difficult?
Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are any copyright issues, please contact us, and we will confirm the copyright based on the materials you provide and pay for the manuscript or delete the content.