Editor's Note: Embedded Systems Architecture, 2nd Edition, is a practical and technical guide to understanding the components that make up an embedded system’s architecture. Offering detailed explanations and numerous code examples, the book provides a comprehensive get-up-and-running reference for those new to the field and those updating their skills. This excerpt offers a introduction and review of device drivers' role in interfacing with and controlling the underlying embedded hardware.
Adapted from “Embedded Systems Architecture, 2nd Edition” by Tammy Noergaard (Newnes)
8.2 Example 2: Memory Device Drivers
While in reality all types of physical memory are two-dimensional arrays (matrices) made up of cells addressed by a unique row and column, the master processor and programmers view memory as a large one-dimensional array, commonly referred to as the memory map (see Figure 8-16). In the memory map, each cell of the array is a row of bytes (8 bits) and the number of bytes per row depends on the width of the data bus (8-, 16-, 32-, 64-bit, etc.). This, in turn, depends on the width of the registers of the master architecture. When physical memory is referenced from the software’s point-of-view it is commonly referred to as logical memory and its most basic unit is the byte. Logical memory is made up of all the physical memory (registers, ROM, and RAM) in the entire embedded system.
Figure 8-16. Sample Memory Map.
The software must provide the processors in the system with the ability to access various portions of the memory map. The software involved in managing the memory on the master processor and on the board, as well as managing memory hardware mechanisms, consists of the device drivers for the management of the overall memory subsystem. The memory subsystem includes all types of memory management components, such as memory controllers and MMU, as well as the types of memory in the memory map, such as registers, cache, ROM, and DRAM. All or some combination of six of the 10 device driver functions from the list of device driver functionality introduced at the start of this chapter are commonly implemented, including:
- Memory Subsystem Startup: initialization of the hardware upon PowerON or reset (initialize translation lookaside buffers (TLBs) for MMU, initialize/configure MMU).
- Memory Subsystem Shutdown: configuring hardware into its PowerOFF state. (Note: Under the MPC860, there is no necessary shutdown sequence for the memory subsystem, so pseudocode examples are not shown.)
- Memory Subsystem Disable: allowing other software to disable hardware on-the-fly (disabling cache).
- Memory Subsystem Enable: allowing other software to enable hardware on-the-fly (enable cache).
- Memory Subsystem Write: storing in memory a byte or set of bytes (i.e., in cache, ROM, and main memory).
- Memory Subsystem Read: retrieving from memory a “copy” of the data in the form of a byte or set of bytes (i.e., in cache, ROM, and main memory).
Regardless of what type of data is being read or written, all data within memory is managed as a sequence of bytes. While one memory access is limited to the size of the data bus, certain architectures manage access to larger blocks (a contiguous set of bytes) of data, called segments, and thus implement a more complex address translation scheme in which the logical address provided via software is made up of a segment number (address of start of segment) and offset (within a segment) which is used to determine the physical address of the memory location.
The order in which bytes are retrieved or stored in memory depends on the byte ordering scheme of an architecture. The two possible byte ordering schemes are little-endian and bigendian. In little-endian mode, bytes (or “bits” with 1-byte (8-bit) schemes) are retrieved and stored in the order of the lowest byte first, meaning the lowest byte is furthest to the left. In big-endian mode bytes are accessed in the order of the highest byte first, meaning that the lowest byte is furthest to the right (see Figure 8-17).
Figure 8-17. Endianess.
To read more, go to: “Device driver pseudocode examples.”