The ‘Library’ Concept in Embedded Device Drivers

I'm Lao Wen, an embedded engineer who loves learning.

Follow me, and let's become better together!

How to write excellent C code?

Excellent code is a crystallization of various programming techniques and design ideas, so it requires step-by-step accumulation. I’m sharing this article on building the ‘library’ concept for everyone to experience.

What if device programs are perfectly library-based?

1. All engineers will spend minimal effort when porting or creating the device driver.

2. As more users adopt it, it becomes stable through testing and transforms into a well-deserved public code.

3. The library’s external interface (function names and their parameter declarations) remains unchanged. When all commonly used devices are implemented as libraries, it brings another benefit: the time spent on porting, creating, modifying, and maintaining the application layer dramatically decreases.

The seamless cross-platform porting of the application layer is not a myth; when all peripheral devices it relies on are library-based on different platforms, implementing the application layer becomes as easy as writing Java code.

4. Libraries also ensure 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 won’t matter.

5. Newcomers can get up to speed faster with library-based projects because they have library documentation for assistance and don’t need to care about low-level details, allowing them to focus on application development.

6. Providing customers with secondary development means you can hand over the hardware and peripheral driver libraries to customers for their own development.

7. The library of communication protocols will make communication system products safer, 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?

These were the design goals of libraries; once they reach the hands of engineers, the effectiveness depends on their skills~

Of course, some engineers might think that libraries can allow them to escape from tedious low-level driver work and engage in higher-level tasks.

Conditions Required for Good Library Creation

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

2. No #define in any .h files; compilation conditions are merely a joke for .lib files.

3. No extern variables in any .h files; if there are, it means the system can only create one such device. For example, if there’s an extern variable in a buzzer driver, it means the entire system only allows one buzzer.

4. Complete and detailed usage documentation.Refer to the help documentation format from Keil.

5. Simple demo programs using the .h files 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 code’s .c files will be split into more .c files based on interface functions to minimize code space during linking.

Of course, everything has its downsides; if libraries were so simple and easy, wouldn’t everyone be using them effortlessly?

Other Considerations:

1. It may slightly slow down device speed due to additional layers of indirect addressing overhead. However, for 32-bit machines, the conveniences it brings are still acceptable.

2. It may consume relatively more code space, but trust me, for a whole medium to large system, it will actually reduce code volume due to many redundant codes in large systems. In my personal experience, the reduction is significant, to an unbelievable extent.

In the early days of 8-bit machines, perfect libraries could not be well implemented, at least not for cross-machine low-level device driver libraries.

In recent years, with the rise of 32-bit machines, libraries have gradually gained favor among more engineers.

The essential 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 51 is also an important reason.

If you have friends 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 the C language – pointers, is perfectly interpreted within it.

Source: Internet, please delete if infringed.

-END-

Previous Recommendations: Click the image to jump to read
The 'Library' Concept in Embedded Device Drivers

What is an Embedded Framework? Why Use a Framework?

The 'Library' Concept in Embedded Device Drivers

Happy weekend! Here’s a share of the world’s healthiest engineer’s schedule!

The 'Library' Concept in Embedded Device Drivers

The Monopoly of Embedded ARM is Gradually Being Broken?

I'm Lao Wen, an embedded engineer who loves learning.

Follow me, and let's become better together!

Leave a Comment