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.4 Board I/O Driver Examples
The board I/O subsystem components that require some form of software management include the components integrated on the master processor, as well as an I/O slave controller, if one exists. The I/O controllers have a set of status and control registers used to control the processor and check on its status. Depending on the I/O subsystem, commonly all or some combination of all of the 10 functions from the list of device driver functionality introduced at the start of this chapter are typically implemented in I/O drivers, including:
- I/O Startup: initialization of the I/O upon PowerON or reset.
- I/O Shutdown: configuring I/O into its PowerOFF state.
- I/O Disable: allowing other software to disable I/O on-the-fly.
- I/O Enable: allowing other software to enable I/O on-the-fly.
- I/O Acquire: allowing other software gain singular (locking) access to I/O.
- I/O Release: allowing other software to free (unlock) I/O.
- I/O Read: allowing other software to read data from I/O.
- I/O Write: allowing other software to write data to I/O.
- I/O Install: allowing other software to install new I/O on-the-fly.
- I/O Uninstall: allowing other software to remove installed I/O on-the-fly.
The Ethernet and RS232 I/O initialization routines for the PowerPC and ARM architectures are provided as examples of I/O startup (initialization) device drivers. These examples are to demonstrate how I/O can be implemented on more complex architectures, such as PowerPC and ARM, and this in turn can be used as a guide to understand how to write I/O drivers on other processors that are as complex or less complex than the PowerPC and ARM architectures. Other I/O driver routines were not pseudocoded in this chapter, because the same concepts apply here as in Sections 8.1 and 8.2. In short, it is up to the responsible developer to study the architecture and I/O device documentation for the mechanisms used to read from an I/O device, write to an I/O device, enable an I/O device, etc.
8.4.1 Example 4: Initializing an Ethernet Driver
Continuing the networking example from Chapter 6, the example used here will be the widely implemented LAN protocol Ethernet, which is primarily based upon the IEEE 802.3 family of standards.
As shown in Figure 8-34, the software required to enable Ethernet functionality maps to the lower section of the OSI (Open Systems Interconnection) data-link layer. The hardware components can all be mapped to the physical layer of the OSI model, but will not be discussed in this section (see Section II).
Figure 8-34. OSI Model.
As mentioned in Section II, the Ethernet component that can be integrated onto the master processor is called the Ethernet Interface. The only firmware (software) that is implemented is in the Ethernet interface. The software is dependent on how the hardware supports two main components of the IEEE802.3 Ethernet protocol: the media access management and data encapsulation.
Data Encapsulation (Ethernet Frame)
In an Ethernet LAN, all devices connected via Ethernet cables can be set up as a bus or star topology (see Figure 8-35).
Figure 8-35. Ethernet Topologies.
In these topologies, all devices share the same signaling system. After a device checks for LAN activity and determines after a certain period there is none, the device then transmits its Ethernet signals serially. The signals are then received by all other devices attached to the LAN—thus the need for an “Ethernet frame,” which contains the data as well as the information needed to communicate to each device which device the data is actually intended for.
Ethernet devices encapsulate data they want to transmit or receive into what are called “Ethernet frames.” The Ethernet frame (as defined by IEEE 802.3) is made of up a series of bits, each grouped into fields. Multiple Ethernet frame formats are available, depending on the features of the LAN. Two such frames (see the IEEE 802.3 specification for a description of all defined frames) are shown in Figure 8-36.
Figure 8-36. Ethernet Frames.
The preamble bytes tell devices on the LAN that a signal is being sent. They are followed by “10101011” to indicate the start of a frame. The media access control (MAC) addresses in the Ethernet frame are physical addresses unique to each Ethernet interface in a device, so every device has one. When the frame is received by a device, its data-link layer looks at the destination address of the frame. If the address doesn’t match its own MAC address, the device disregards the rest of the frame.
The Data field can vary in size. If the data field is less than or equal to 1500 then the Length/Type field indicates the number of bytes in the data field. If the data field is greater than 1500, then the type of MAC protocol used in the device that sent the frame is defined in Length/Type. While the data field size can vary, the MAC Addresses, the Length/Type, the Data, Pad, and Error checking fields must add up to be at least 64 bytes long. If not, the Pad field is used to bring up the frame to its minimum required length.
The Error checking field is created using the MAC Addresses, Length/Type, Data Field, and Pad fields. A 4-byte CRC (cyclical redundancy check) value is calculated from these fields and stored at the end of the frame before transmission. At the receiving device, the value is recalculated, and, if it doesn’t match, the frame is discarded.
Finally, remaining frame formats in the Ethernet specification are extensions of the basic frame. The VLAN (virtual local-area network) tagging frame shown above is an example of one of these extended frames, and contains two additional fields: 802.1Q tag type and Tag Control Information. The 802.1Q tag type is always set to 0.8100 and serves as an indicator that there is a VLAN tag following this field, and not the Length/Type field, which in this format is shifted 4-bytes over within the frame. The Tag Control Information is actually made up of three fields: the user priority field (UPF), the canonical format indicator (CFI), and the VLAN identifier (VID). The UPF is a 3-bit field that assigns a priority level to the frame. The CFI is a 1-bit field to indicate whether there is a Routing Information Field (RIF) in the frame, while the remaining 12 bits is the VID, which identifies which VLAN this frame belongs to. Note that while the VLAN protocol is actually defined in the IEEE 802.1Q specification, it’s the IEEE 802.3ac specification that defines the Ethernet-specific implementation details of the VLAN protocol.
Media Access Management
Every device on the LAN has an equal right to transmit signals over the medium, so there have to be rules that ensure every device gets a fair chance to transmit data. Should more than one device transmit data at the same time, these rules must also allow the device a way to recover from the data colliding. This is where the two MAC protocols come in: the IEEE
802.3 Half-Duplex Carrier Sense Multiple Access/Collision Detect (CDMA/CD) and the IEEE 802.3x Full-Duplex Ethernet protocols. These protocols, implemented in the Ethernet interface, dictate how these devices behave when sharing a common transmission medium. Half-Duplex CDMA/CD capability in an Ethernet device means that a device can either receive or transmit signals over the same communication line, but not do both (transmit and receive) at the same time. Basically, a Half-Duplex CDMA/CD (also known as the MAC sublayer) in the device can both transmit and receive data, from a higher layer or from the physical layer in the device. In other words, the MAC sublayer functions in two modes: transmission (data received from higher layer, processed, then passed to physical layer) or reception (data received from physical layer, processed, then passed to higher layer). The transmit data encapsulation (TDE) component and the transmit media access management (TMAM) components provide the transmission mode functionality, while the receive media access management (RMAM) and the receive data decapsulation (RDD) components provide the reception mode functionality.
To read more, go to: “CDMA/CD (MAC Sublayer) Transmission Mode.”