Embedded Systems Architecture, Device

Drivers - Part 3: On-board bus device drivers

Tammy Noergaard - March 19, 2013

Editor's Note: Embedded Systems Architecture, 2nd Edition, is a practical

and technical guide to understanding the components that make up an
embedded systems architecture. Offering detailed explanations and
numerous code examples, the book provides a comprehensive get-up-ad-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
offered a detailed look at how device drivers handle management of an
embedded system's overall memory subsystem. In this installment, the author examines how device
drivers support on-board bus protocols.
Adapted from "Embedded Systems Architecture, 2nd Edition" by Tammy Noergaard (Newnes)

8.3 Example 3: On-Board Bus Device Drivers

As discussed in Chapter 7, associated with every bus is/are (1) some type of protocol that defines
how devices gain access to the bus (arbitration), (2) the rules attached devices must follow to
communicate over the bus (handshaking), and (3) the signals associated with the various bus lines.
Bus protocol is supported by the bus device drivers, which commonly include all or some
combination of all of the 10 functions from the list of device driver functionality introduced at the
start of this chapter, including:

Bus Startup: initialization of the bus upon PowerON or reset.

Bus Shutdown: configuring bus into its PowerOFF state.
Bus Disable: allowing other software to disable bus on-the-fly.
Bus Enable: allowing other software to enable bus on-the-fly.
Bus Acquire: allowing other software to gain singular (locking) access to bus.
Bus Release: allowing other software to free (unlock) bus.
Bus Read: allowing other software to read data from bus.
Bus Write: allowing other software to write data to bus.
Bus Install: allowing other software to install new bus device on-the-fly for expandable buses.
Bus Uninstall: allowing other software to remove installed bus device on-the-fly for expandable
buses.

Which of the routines are implemented and how they are implemented depends on the actual bus.
The pseudocode below is an example of an I2C bus initialization routine provided as an example of a

bus startup (initialization) device driver on the MPC860.

8.3.1 On-Board Bus Device Driver Pseudocode Examples

The following pseudocode gives an example of implementing a bus initialization routine on the
MPC860, specifically the startup function in reference to the architecture. These examples
demonstrate how bus management can be implemented on a more complex architecture, and this
can be used as a guide to understand how to write bus management drivers on other processors of
equal or lesser complexity than the MPC860 architecture. Other driver routines have not been
pseudocoded, because the same concepts apply here as in Sections 8.1 and 8.2essentially, looking
in the architecture and bus documentation for the mechanisms that enable a bus, disable a bus,
acquire a bus, etc.
Title-1
I2C Bus Startup (Initialization) on the MPC860
The I2C (inter-IC) protocol is a serial bus with one serial data line (SDA) and one serial clock line
(SCL). With the I2C protocol, all devices attached to the bus have a unique address (identifier), and
this identifier is part of the data stream transmitted over the SDL line.
The components on the master processor that support the I2C protocol are what need initialization.
In the case of the MPC860, there is an integrated I2C controller on the master processor (see Figure
8-29). The I2C controller is made up transmitter registers, receiver registers, a baud rate generator,
and a control unit. The baud rate generator generates the clock signals when the I2C controller acts
as the I2C bus masterif in slave mode, the controller uses the clock signal received from the
master. In reception mode, data is transmitted from the SDA line into the control unit, through the
shift register, which in turn transmits the data to the receive data register. The data that will be
transmitted over the I2C bus from the PPC is initially stored in the transmit data register and
transferred out through the shift register to the control unit and over the SDA line. Initializing the
I2C bus on the MPC860 means initializing the I2C SDA and SCL pins, many of the I2C registers,
some of the parameter RAM, and the associated buffer descriptors.

Figure 8-29. I2C Controller on MPC860.[4] Freescale Semiconductor, Inc. Used by

permission.

The MPC860 I2C SDA and SCL pins are configured via the Port B general purpose I/O port (see
Figures 8-30a and b). Because the I/O pins can support multiple functions, the specific function a pin
will support needs to be configured via port Bs registers (shown in Figure 8-30c). Port B has four
read/write (16-bit) control registers: the Port B Data Register (PBDAT), the Port B Open Drain

Register (PBODR), the Port B Direction Register (PBDIR), and the Port B Pin Assignment Register
(PBPAR). In general, the PBDAT register contains the data on the pin, the PBODR configures the pin
for open drain or active output, the PBDIR configures the pin as either an input or output pin, and
the PBPAR assigns the pin its function (I2C, general purpose I/O, etc.).

Figure 8-30a. SDA and SCL pins on MPC860.[4] Freescale Semiconductor, Inc. Used by
permission.

Figure 8-30b. MPC860 Port B Pins.[4] Freescale Semiconductor, Inc. Used by

permission.

Figure 8-30c. MPC860 Port B Register.[4] Freescale Semiconductor, Inc. Used by

permission.
Title-2
An example of initializing the SDA and SCL pins on the MPC860 is given in the pseudocode below.

The I2C registers that need initialization include the I2C Mode Register (I2MOD), I2C Address
Register (I2ADD), the Baud Rate Generator Register (I2BRG), the I2C Event Register (I2CER), and
the I2C Mask Register (I2CMR) shown in Figures 8-31ae).
An example of I2C register initialization pseudocode is as follows:

Figure 8-31a. I2MOD.[2]

Figure 8-31b. I2ADD.[2]

Figure 8-31c. I2BRG.[2]

Figure 8-31d. I2CER.[2]

Figure 8-31e. I2CMR.[2]

Five of the 15 field I2C parameter RAM need to be configured in the initialization of I2C on the
MPC860. They include the receive function code register (RFCR), the transmit function code register

(TFCR), and the maximum receive buffer length register (MRBLR), the base value of the receive
buffer descriptor array (Rbase), and the base value of the transmit buffer descriptor array (Tbase)
shown in Figure 8-32.
Click for larger image

Figure 8-32. I2C Parameter RAM.[4]

Title-3
See the following pseudocode for an example of I2C parameter RAM initialization:

Data to be transmitted or received via the I2C controller (within the CPM of the PowerPC) is input
into buffers which the transmit and receive buffer descriptors refer to. The first half word (16 bits)
of the transmit and receive buffer contain status and control bits (as shown in Figures 8-33a and b).
The next 16 bits contain the length of the buffer.

Figure 8-33a. Receive Buffer Descriptor.[2]

Figure 8-33b. Transmit Buffer Descriptor.[2]

In both buffers the Wrap (W) bit indicates whether this buffer descriptor is the final descriptor in the
buffer descriptor table (when set to 1, the I2C controller returns to the first buffer in the buffer
descriptor ring). The Interrupt (I) bit indicates whether the I2C controller issues an interrupt when
this buffer is closed. The Last bit (L) indicates whether this buffer contains the last character of the
message. The CM bit indicates whether the I2C controller clears the Empty (E) bit of the reception
buffer or Ready (R) bit of the transmission buffer when it is finished with this buffer. The Continuous
Mode (CM) bit refers to continuous mode in which, if a single buffer descriptor is used, continuous
reception from a slave I2C device is allowed.
In the case of the transmission buffer, the Ready (R) bit indicates whether the buffer associated with

this descriptor is ready for transmission. The Transmit Start Condition (S) bit indicates whether a
start condition is transmitted before transmitting the first byte of this buffer. The NAK bit indicates
that the I2C aborted the transmission because the last transmitted byte did not receive an
acknowledgement. The Under-run Condition (UN) bit indicates that the controller encountered an
under-run condition while transmitting the associated data buffer. The Collision (CL) bit indicates
that the I2C controller aborted transmission because the transmitter lost while arbitrating for the
bus. In the case of the reception buffer, the Empty (E) bit indicates if the data buffer associated with
this buffer descriptor is empty and the Over-run (OV) bit indicates whether an overrun occurred
during data reception.
An example of I2C buffer descriptor initialization pseudocode would look as follows:

2013 Elsevier, Inc. All rights reserved.

Printed with permission from Newnes, a division of Elsevier. Copyright 2013. For more
information on this title and other similar books, please visit www.newnespress.com.
If you liked this and would like to see a weekly collection of related products and features delivered
directly to your inbox, click here to sign up for the EDN on Systems Design newsletter.