UNIT 3

Board I/O (Input/Output)

Input/output (I/O) components on a board are responsible for moving information into and
out of the board to I/O devices connected to an embedded system. Board I/O can consist of
input components, which only bring information from an input device to the master
processor; output components, which take information out of the master processor to an
output device; or components that do both.
Serial vs. Parallel I/O
Board I/O that can transmit and receive data in serial is made up of components in which
data (characters) are stored, transferred and received one bit at a time. Serial I/O hardware is
typically made up of some combination of the six main logical units outlined at the start of
the chapter. Serial communication includes within its I/O subsystem a serial port and a serial
interface.
Serial interfaces manage the serial data transmission and reception between the master CPU
and either the I/O device or its controller. They include reception and transmission buffers to
store and encode or decode the data they are responsible for transmitting either to the master
CPU or an I/O device. Serial data transmission and reception schemes generally differ in
terms of the direction data can be transmitted and received, as well as the actual transmission/
reception process—in other words, how the data bits are transmitted and received within the
data stream.
Data can be transmitted between two devices in one of three directions:

Serial I/O data communication that uses a implex scheme is one in which a data stream can
only be transmitted—and thus received—in one direction.
A half duplex scheme is one in which a data stream can be transmitted and received in either
direction, but in only one direction at any one time.
A full duplex scheme is one in which a data stream can be transmitted and received in
either direction simultaneously.
serial I/O transfers can occur either as a steady (continuous) stream at regular intervals regulated by
the CPU’s clock, referred to as a synchronous transfer, or intermittently at irregular (random)
intervals, referred to as an asynchronous transfer.

Serial I/O Example 1: Networking and Communications: RS-232

One of the most widely implemented serial I/O protocols for either synchronous or
asynchronous transmission is the RS-232 or EIA-232 (Electronic Industries Association-232),
which is primarily based upon the Electronic Industries Association family of standards.
These standards define the major components of any RS-232 based system, which is
implemented almost entirely in hardware.
Parallel I/O
Components that transmit data in parallel are devices which can transfer data in multiple bits
simultaneously. Just as with serial I/O, parallel I/O hardware is also typically made up of
some combination of six main logical units, as introduced at the start of this chapter, except
that the port is a parallel port and the communication interface is a parallel interface.

Parallel interfaces manage the parallel data transmission and reception between the master
CPU and either the I/O device or its controller. They are responsible for decoding data bits
received over the pins of the parallel port (transmitted from the I/O device)—and receiving
data being transmitted from the master CPU, and then encoding these data bits onto the
parallel port pins.

Parallel I/O Example 3: “Parallel” Output and Graphics I/O

Technically, the models and images that are created, stored, and manipulated in an embedded
system are the graphics. There are typically three logical components (engines) of I/O
graphics on an embedded board, as shown in Figure 6-14:
The geometric engine, which is responsible for defining what an object is. This includes
implementing color models, an object’s physical geometry, material and lighting properties,
and so on.
The rendering engine, which is responsible for capturing the description of objects. This
includes providing functionality in support of geometric transformations, projections,
drawing, mapping, shading, illumination, and so on.
The raster and display engine, which is responsible for physically displaying the object. It is
in this engine that the output I/O hardware comes into play.

An embedded system can output graphics via softcopy (video) or hardcopy (on paper) means.
The contents of the display pipeline differ according to whether the output I/O device outputs
hard or soft graphics, so the display engine differs accordingly.
The actual parallel port configuration differs from standard to standard in terms of the
number of signals and the required cable.
Interfacing an I/O Controller and the Master CPU
In a subsystem that contains an I/O controller to manage the I/O device, the
design of the
interface between the I/O controller and master CPU—via a communications
interface—is
based on four requirements:

An ability of the master CPU to initialize and monitor the I/O Controller.

I/O controllers can typically be configured via control registers and monitored
via status
registers. These registers are all located on the I/O controller. Control registers
are
data registers that the master processor can modify to configure the I/O
controller.
Status registers are read-only registers in which the master processor can get
information
as to the state of the I/O controller. The master CPU uses these status and control
registers to communicate and/or control attached I/O devices via the I/O
controller.

A way for the master processor to request I/O.

The most common mechanisms used by the master processor to request I/O via
the I/O controller are special I/O instructions (I/O mapped) in the ISA and
memory-mapped I/O, in which the I/O controller registers have reserved spaces
in main memory.

A way for the I/O device to contact the master CPU.

I/O controllers that have the ability to contact the master processor via an
interrupt are referred to as interrupt driven I/O. Generally, an I/O device initiates
an asynchronous interrupt requesting signaling to indicate (for example) control
and status registers can be read from or written to. The master CPU then uses its
interrupt scheme to determine when an interrupt will be discovered.

Some mechanism for both to exchange data.

This refers to how data is actually exchanged between the I/O controller and the
master processor. In a programmed transfer, the master processor receives data
from the I/O controller into its registers, and the CPU then transmits this data to
memory. For memory-mapped I/O schemes, DMA (direct memory access)
circuitry can be used to bypass the master CPU entirely.
DMA has the ability to manage data transmissions or receptions directly to and
from main memory and an I/O device. On some systems, DMA is integrated into
the
master processor, and on others there is a separate DMA controller. Essentially,
DMA
requests control of the bus from the master processor.

I/O and Performance

I/O performance is one of the most important issues of an embedded design. I/O
can negatively impact performance by bottlenecking the entire system. In order
to understand the type of performance hurdles I/O must overcome, it is
important to understand that, with the wide variety of I/O devices, each device
will have its own unique qualities.

Common features of I/O that can negatively impact board performance

include:

The data rates of the I/O devices. I/O devices on one board can vary in data
rates
from a handful of characters per second with a keyboard or a mouse to devices
that
can transmit in Mbytes per second (networking, tape, disk).
The speed of the master processor. Master processors can have clocks rates
anywhere
from tens of MHz to hundreds of MHz. Given an I/O device with an extremely
slow data rate, a master CPU could have executed thousands of times more data
in
the time period that the I/O needs to process a handful of bits of data.With
extremely
fast I/O, a master processor would not even be able to process anything before
the I/O
device is ready to move forward.
How to synchronize the speed of the master processor to the speeds of
I/O. Given
the extreme ranges of performance, a realistic scheme must be implemented
that
allows for either the I/O or master processor to process data successfully
regardless
of how different their speeds. Otherwise, with an I/O device processing data
much
slower than the master processor transmits, for instance, data would be lost by
the I/O
device. If the device is not ready, it could hang the entire system if there is no
mechanism
to handle this situation.
How I/O and the master processor communicate. This includes whether
there is an
intermediate dedicated I/O controller between the master CPU and I/O device
that
manages I/O for the master processor, thus freeing up the CPU to process data
more
efficiently. Relative to an I/O controller, it becomes a question whether the
communication
scheme is interrupt driven, polled, or memory mapped (with dedicated DMA
to, again, free up the master CPU). If interrupt-driven, for example, can I/O
devices
interrupt other I/O, or would devices on the queue have to wait until previous
devices
finished their turn, no matter how slow.
Parameters to measure I/O performance:
Throughput of the various I/O components (the maximum amount of data per
unit time that can be processed, in bytes per second). This value can vary for
different components. The components with the lowest throughput are what
drives the performance of the whole system.
The execution time of an I/O component. The amount of time it takes to
process all
of the data it is provided with.
The response time or delay time of an I/O component. It is the amount of time
between
a request to process data and the time the actual component begins processing.

In order to accurately determine the type of performance to measure, the

benchmark has to match how the I/O functions within the system.
If the board will be accessing and processing several larger stored data files,
benchmarks will be needed to measure the throughput between memory and
secondary/tertiary storage medium.
If the access is to files that are very small, then response time is the critical
performance measure, since execution times would be very fast for small files,
and the I/O rate would depend on the number of storage accesses per second,
including delays.