Using pre-configured device drivers to reduce memory footprint - Embedded.com

Using pre-configured device drivers to reduce memory footprint

In embedded systems, the predominant bottle-neck is the size of the binaries and the RAM used. The large memory size results in an increase in the cost of the final system due to the large FLASH and RAM.

However, by using preconfigured device (PCD) driver techniques developers can significantly reduce the usage of memory to minimize the cost of the final product with only slight changes in the conventional development method/technique.

PCD does not require any extra hardware or critical software development. At present, the developed code is rewritten, such that the final binary is smaller in size. Moreover, the start-up of the device driver is faster compared to the original one.

How PCD works
In embedded systems, the majority of the device driver code is written to configure the driver. This code moves through lots of if-else or switch statements – the algorithm developed to calculate the parameter values.

However, in most of the cases, the final product uses only one of the settings in the entire life cycle. If the driver is pre-configured to the final value, using configuration files, the if-else and switch statements (the configuration algorithm) are eliminated, which leads to occupation of the space on the system memory.

In this PCD method, the if-else and switch statements still exist, though not inside the device driver, but through the use of an external Device Driver Configuration tool (Figure 1, below ). This external tool is designed using the same architecture/algorithm as the configuration module of the device driver.

This tool is responsible for generating configuration values in a usable form, in order to reduce development time. The output of the tool is source code that can be compiled and made part of the final device driver.

Figure 1. The use of a Preconfigured Device Driver is used to generate configuration values in a usable form, significantly reducing development time.

Building the PCD Tool
Development of the PCD tool is quite straightforward. As explained earlier, the same algorithm is reused along with a little coding.

1. Remove the configuration algorithm from the driver source file and copy it to a new file, for example, pcd_config.c.
2. Add the entry function, main(), to the pcd_config.c file.
3. In the entry function, open a text file, driver.h, for output. This file later serves as the header file containing the final configuration of the driver.
4. Predefine the configuration parameters in the pcd_config.c file (or in an external text file, for which a external text file parser is required to parse the file)
5. Pass these configuration parameters to the configuration algorithm and store the output in the driver.h file opened earlier.
6. Include the header file driver.h in the driver source file.
7. Read the final configuration parameters from the driver.h file and program the hardware registers accordingly.
8. Update the make file, to compile pcd_config.c, in order to execute it and compile the driver source.
9. The driver is configured with the pre-defined configuration parameters and is ready to use.

Below is an example of such a driver tool written for the C language. However, shell scripts, etc., can also be used to develop the PCD tool.

In the normal UART driver, there is a big module to configure the UART to any configuration (eg: 115200-8N1). Instead of using this configuration module, we can develop a PCD tool, which generates the C code, containing a structure populated with the final values used to configure the UART IP.

The generated code will directly be compiled and linked with the final software.

In one of my projects I have used the PCD technique for UART, and the memory footprint was reduced by almost 4K.

This technique can be used for the rest of the device drivers in the system, such as SPI, SMI, I2C, ADC, etc., to reduce the final footprint of the system.

The PCD method reduces the memory usage of the system and makes the driver start-up faster, thus resulting in faster start-up and optimum memory performance.

Ashutosh Sharma is a Project Manager in the Computer System Division at STMicroelectronics.

This article was previously published on EETimes Designline.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.