Refining the CCU
Last Edit November 2, 1996; May 1, 1999; July 7, 2001
In a microcomputer system there is a need to interface the main
or central unit (microprocessor and/or control unit) to one or more
external devices such as sensors, displays, control panels, keyboards
or external memory. The main objective is to design the interface
to minimize the effect of the interface activities on the system
throughput or performance. Any contact with any external device
will be considered as input/output handling or I/O.
Although there are many schemes for handling I/O requests, interrupts
and queuing will be covered very lightly herein, principally as
a means of alerting the designer to the existence of the problems.
(The subject warrants its own seminar.) Only those schemes relevant
to firmware design will be explored in any detail.
There are two very basic methods of I/O handling - status polling
and interrupt servicing.
With status polling, the controlling unit must interrogate each
peripheral to determine if it needs servicing by testing the status
line of each peripheral, one at a time.
This might be by the elementary "Round Robin" approach, where the
devices are tested in a set, circular sequence. Where different
devices are to be handled on a priority basis, priority is accomplished
by assigning high-priority devices to more than one location in
the testing sequence. A high-priority device is tested with a higher
polling frequency than the low-priority items.
Figure 4-1 Status polling microprogram flowchart
- One problem with status polling is that a device requesting
service must wait for its turn even if all other devices are inactive.
- The controlling unit, a processor or a controller, must waste
time testing inactive status lines; this reduces the possible
- With the sequence test under microprogram control, a long microroutine
is necessary, since each status test requires its own microinstruction.
- In terms of the requesting device, the system response is relatively
When to Use or Not Use
The scheme is suitable if the frequency of service requests for
each device is known with some degree of accuracy. This allows the
polling frequency to be custom-tailored to the system. The service
time, once a request for service is acknowledged, should be long
compared to the estimated wait time.
It is not an advisable scheme where interfacing to a human is involved;
that is, requests should be primarily I/O to hardware devices. (Human
patience tends to decrease with exposure to computers; and has dropped
from minutes (way back) to 30 sec (60's) to 1-3 sec. Look at the
operating speeds of 1980's PCs (200-250MHz) compared to 16MHz systems,
and the forecasted 500MHz systems (1998-9). Even children's game
systems are at 64-bit computing speeds and climbing and these children
will demand even faster response.
Or, watch someone trying to access the Internet during internet
traffic jams. Humans want instant gratification. The normal
phone connection came and went in and out of vogue in less than
three years because it is not fast enough to keep up with the increasingly
more demanding computer user.