INTRODUCTION
The Intel 8259A
is
a Programmable Interrupt
Controller
(PIC) designed for use in real-time interrupt driven
microcomputer systems. The 8259A manages eight
levels
of
interrupts and has
built'in
features for expan·
sion up to
64
levels
with
additional 8259A·s.
Its
versatile
design allows it to
be
used
within
MCS·80, MCS·85,
MCS-86, and MCS·88 microcomputer systems. Being
fully programmable, the 8259A provides a wide variety of
modes and commands
to
tailor 8259A interrupt process·
ing for the
specific
needs
of
the user. These modes and
commands
control
a number
of
interrupt oriented func·
tions
such as interrupt
priority
selection and masking
of
interrupts. The 8259A programming may be dynamically
changed by the software at any time, thus
allowing
com·
plete interrupt control throughout program execution.
The 8259A is
an
enhanced, fully compatible revision
of
its
predecessor, the 8259. This means the 8259A can use
all hardware
and
software originally designed for the
8259
without
any changes. Furthermore, it provides ad·
ditional
modes that increase
its
flexibility
in MCS·80
and MCS-85
systems
and allow
it
to
work in MCS-86 and
MCS·88 systems. These modes are:
• MCS·86/88 Mode
•
Automatic
End
of
Interrupt Mode
• Level Triggered Mode
• Special Fully Nested Mode
• Buffered
Mode
Each
of
these are covered in depth further in this appli-
cation
note.
This
application
note was
written
to
explain completely
how
to
use
the
8259A
within
MCS-80, MCS·85, MCS·86,
and
MCS-88
microcomputer
systems.
It
is
diVided
into
five sections. The
first
section,
"Concepts"'-1xplains
the
concepts
of
interrupts
and presents an overview
of
how the 8259A works
with
each
microcomputer
system
mentioned above. The second section,
"Functional
Block Diagram", describes the internal
functions
of
the
8259A
in
block
diagram form and provides a detailed
functional
description
of
each device pin.
"Operation
of
the
8259A", the
third
section, explains in depth the
operation and use
of
each
of
the 8259A modes and com·
mands.
For
clarity
of
explanation,
this
section
doesn't
make reference
to
the actual programming
of
the 8259A.
Instead, all programming
is
covered in the fourth sec·
tion,
"Programming
the 8259A". This
section
explains
how
to
program the 8259A with the modes and com·
mands mentioned in the previous section.
The reader should note that some
of
the terminology
used
throughout
this
application note may
differ
slightly
from
existing
data sheets. This is done
to
better
clarify
and explain the operation and programming
of
the 8259A.
1. CONCEPTS
In
microcomputer
systems there is usually a need for
the processor
to
communicate
with
various Input/Out·
put
(I/O)
devices such as keyboards. displays. sensors.
and other peripherals From the system
VieWpOint.
the
processor should spend as
little
time as
POSSible
servlc·
109
lhe
peripherals since the time required for these
1/0
chores directly
affects
the amount of time available for
34
other tasks. In other words. the system should
be
designed so that
110
servicing has
little
or
no effect
on
the total system throughput. There are two basic
methods
of
handling the
110
chores in a system: status
polling and interrupt servicing.
The status poll method
of
110
serVicing essentially in·
volves having the processor "aSk" each peripheral II It
needs servicing
by
testing the peripheral's status line. If
the
peripheral requires service, the processor branches
to
the appropriate service routine:
il
not. the processor
continues
with
the main program. Clearly, there are
several problems in implementing such
an
approach.
First, how often a peripheral is polled is
an
important
constraint. Some idea of the "freQuency·ol-service"
required by each peripheral must
be
known and any soft·
ware written for the system must accommodate thiS
time
dependence by
"scheduling"
when a device is
polled. Second, there will obviously
be
times when a
device is polled
that is not ready for service, wasting the
processor time that
it
took
to
do
the poll. And other
times, a ready device would have to wait until the proc-
essor "makes
its
rounds" before it could
be
serviced.
slowing
down the peripheral.
Other problems arise when certain peripherals are more
important than others. The only way
to
implement the
"priority"
of
devices is to poll the high Priority deVices
more frequently than lower priority ones. It may even be
necessary
to
poll the high priority devices while in a low
priority device service routine. It
is
easy to see that the
polled approach can be
inefficient
both t,me,w,se and
software,wise. Overall, the polled method of I/O servlc·
ing
can have a detrimental effect· on system throughput.
thus
limiting
the tasks that can be performed by the
processor.
A more desirable approaCh in
most
systems would allow
the processor to be executing
its
main program and only
stop
to service the
110
when told
to
do so by the
110
itself. This
is
called the interrupt service methOd. In
effect,
the
device would asynchronously Signal the proc·
essor when it required service. The processor would
finish
its
current
instruction
and then vector to the
service routine for the device requesting service Once
the
service routine is complete. the processor would
resume exactly where it left off. Using the interrupt ser·
vice method, no processor time
IS
spent
testing
deVices.
scheduling is not needed, and
priority schemes are
readily implemented.
illS
easy to see that. uSing the
In·
terrupt service approach. system throughput would
In
crease, allowing more tasks to
be
handled
by
the
processor.
However.
to
Implement the Interrupt service method
between processor and
peripherals. additional hardware
is
usually reqUired.
ThiS
is because. alter interrupting
the processor, the deVice must supply
,"'ormation
for
vectoring program
e~ecutlon
Depending
on
the proc·
essor used. thiS can
be
accomplished
by
the deVice
lak·
ing cOnlrol ot the data bus and
"lamming'
an
InSlruc
tion(sl
onto
It. The instruct,on/Sl then vectors the pro
gram
to
the proper service routine. This of course
re-
quires additional
control
logiC for each Interrupt
reo
Questing deVice. Yet the implementation so far IS only in
the most
baSIC
form. What If certain peripherals are to