BSP Developer's Guide

5
Driver Guidelines
Maintenance and Readability
Most code work is maintenance. Thus, any effort that makes maintenance simpler
is valuable. Adherence to coding standards and quality documentation makes
code easy to read, easy to understand, and easy to maintain. The concern should
be on why things happen. Poor quality documentation is just as bad as insufficient
documentation. All new documentation should be reviewed by at least one other
person.
5
Ease of Configuration
Drivers should not limit the end-user’s options or requirements. Do not impose
limits on the number of devices to be supported or other features. You may not be
able to support all features or modes for a device, but the design should not
preclude their support at a later time.
Performance Testing
All drivers must be tested for performance. In addition to writing the driver, the
engineer must also consider test routines. This involves inserting debug
information as well as benchmark tests. If a standard benchmark test is not
available, then the engineer must consider writing one. Performance testing
should be considered for all types of device drivers, ethernet, SCSI, serial, timers,
interrupt controllers, and the like.
Code Size
In the embedded RTOS market, code size is important. Code size should be
minimized through good structured design. Reducing code size can hurt
performance. The engineer must balance the design to provide performance
without excessive code size.
Reentrancy
Drivers should be fully re-entrant in order to support any number of devices.
Drivers that limit the number of supported devices are not desirable. Instead of
fixed arrays of device information, the user should create a structure for each new
device and pass it to the driver for initialization and control. Alternatively, the
91