I am Lao Wen, an embedded engineer who loves learning.Follow me to become even better together!
1. Benefits of Encapsulating into Libraries
If a device program is perfectly encapsulated into a library, it means:
1. The cost for all engineers to port or create the device driver is minimal.
2. As the number of users increases, it has been tested and becomes increasingly stable, turning into truly public code.
3. The external interface of the library (function names and their parameter declarations) remains unchanged. When all commonly used devices are encapsulated into libraries, it brings another benefit: the time spent on porting, creating, modifying, and maintaining the application layer will be significantly reduced.
The seamless cross-platform porting of the application layer is not a myth. When all peripheral devices it relies on are encapsulated into libraries on different platforms, implementing the application layer becomes as straightforward as writing Java code.
4. Libraries also mean the security of the company’s core code. The library code is only in the hands of core engineers, so even if the application layer program is lost, it doesn’t matter.
5. Newcomers can get up to speed faster with these library-based projects. First, there is documentation to help with the library, and second, they do not need to concern themselves with the underlying 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 their secondary development.
7. The encapsulation of communication protocols will make products in communication systems more secure, at least preventing damage from engineers who leave the company, such as in RFID payment systems.
8. And so on~
So, isn’t it cool to design and organize code using libraries? At that time, these were the design goals of libraries, but what effects can be achieved when it reaches the hands of engineers depends on their skill level.
Of course, some engineers might think that libraries can help them avoid tedious low-level driver work and engage in higher-level tasks.
2. Considerations for Encapsulating into Libraries
To create a good library, the following conditions must be met:
1. Only .h and .lib files should be provided to customers.
2. There should be no #define in any .h files; compilation conditions are just a joke for .lib files.
3. There should be 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. You can refer to the help documentation format of Keil.
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-related 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 code in .c files will be split into more .c files based on interface functions to minimize code space during linking.
3. The Dual Nature of Libraries
Of course, everything has its duality. If libraries were so simple and easy, wouldn’t everyone be able to use them effortlessly? Therefore, there are also some issues that need to be considered.
1. It may slow down device speed slightly due to additional layers of indirect addressing. However, for 32-bit machines, the convenience it brings is still acceptable.
2. It may consume relatively more code space, but trust me, for an entire medium to large system, it will actually reduce the code size instead of increasing it, because large systems often have 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, the 51 platform could not implement a perfect library well, at least it could not create a cross-model low-level device driver library.
In recent years, with the rise of 32-bit machines, libraries have gradually gained favor among more and more engineers.
The fundamental reason for this is that the stack of the 51 architecture is statically compiled, and local variables and parameter stacks are also static, making functions non-reentrant.
In contrast, most 32-bit machines 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 of Linux low-level drivers is a world of function pointers and structure pointers. The essence of C lies in pointers, which is perfectly illustrated in this context.
Source: Embedded ARM
-END-
Previous Recommendations: Click the image to jump to read
Embedded C Language: A Detailed Explanation of the Implementation Principle of Zero-Length Arrays.
Embedded Communication Protocol: How to Efficiently Parse Variable-Length Data Frames?
These 7 Design Tips Will Make Your Embedded Programs More Stable and Reliable!
I am Lao Wen, an embedded engineer who loves learning.Follow me to become even better together!