Embedded Systems Architecture, Device Drivers - Part 4: Board I/O Drivers

March 26, 2013

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.

In part 1, the author introduces device drivers and presents a close look at device drivers for interrupt handling with detailed examples. In part 2, the author offers a detailed look at how device drivers handle management of an embedded system's overall memory subsystem. In part 3, the author examines how device drivers support on-board bus protocols. In this installment, the author offers examples and a detailed explanation on how drivers manage board I/O subsystem components.

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).

Click for larger image

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.

Click for larger image

Figure 8-36. Ethernet Frames.[7]
Next: Title-1

Loading comments...

Write a Comment

To comment please Log In