Introduction
7
has data ready for transferring to the CPU. Subsequently when the device is polled,
the processor
reads this status and goes on to read the data in. Similarly when the CPU has data to output, it
polls the device to check for a ready status, upon which data is then written into the peripheral
device. Several such I/O devices can be polled in succession, with the processor jumping to
different I/O
software routines, depending on which flags have been set.
Polling works well if a minimum amount of processing is required in response to each set
flag. For slow I/O transfers, the processor will be spending most of its time in its polling loop,
asking each I/O device in turn if it has any data ready. This amount to wasted time, during which
the CPU could be carrying out other useful tasks. In applications where there is little else for the
processor to do (such
as in keyboard scanning, for example), this is fine, but for applications
which involve substantial calculation as well, this amounts to inefficient use of the processor. The
advantage of the polling technique is its simplicity.
0.5.2.
Interrupts
Rather than have the CPU continually asking I/O devices whether they have any data
available (and finding most of the time that they have not), a more efficient method is to have the
I/O devices tell the processor when they have data ready. The processor
can be carrying out its
normal function, only responding to I/O transfers when there is data to respond to. On receipt of
an interrupt, the CPU suspends its current operation (storing the contents of its program counter,
SR and other registers), identifies the interrupting device,
then jumps (vectors) to the appropriate
interrupt service routine (interrupt handler).
The advantages of
interrupts, compared with polling, are the speed of response to external
events and the reduced software overhead (of continually asking I/O devices whether they have
any data ready). Its main disadvantages are software commissioning
and maintenance, and the
additional hardware overhead required (in the form of device identification, supplying vector
information and priority resolution).
A typical interrupt interface requires two handshake controls. The two handshake control
lines that interface between the CPU and I/O port are Interrupt Request and Interrupt
Acknowledge. Most systems will have more than one I/O port, with its
associated set of interrupt
handshake lines, so that some form of external (hardware) arbitration will be necessary in order
to resolve priorities. This priority resolver decides in which order the devices will be serviced in
the event of multiple interrupt requests occurring.
With more than one possible interrupting device, a priority must be allocated to each.
Within the CPU it will therefore be necessary to mask off lower priority interrupts, and to
respond only to those of higher priority (non-maskable interrupts, however, must always be
responded to by the processor, a typical example being a system control console). In cases where
several devices are allocated the same priority level, additional external hardware (in the form of
a PIC) will be necessary.
There will be some means within the CPU whereby interrupts can be enabled and disabled.
For example, the very first function performed by the interrupt handler is to 'disable further
interrupts', so that the current interrupt can be attended to first. Any interrupts that occur during
the servicing of this first one will usually be latched into the I/O port, and
remain pending until
the processor is ready to deal with them (that is, providing their priority level was higher than the
current mask).
Some processors also provide an auto vector facility, whereby the starting location of the
interrupt service routine can be set automatically within the CPU, depending on its priority level.
www.lintech.org