Zilog Z16C30 - Manual (Page 152)

7-24
Z16C30 USC ®
U SER ' S M ANUAL
UM97USC0100
Z ILOG
7.15 INTERRUPT VECTORS (Continued)
7.16 SOFTWARE REQUIREMENTS
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15
Interrupt Vector 7-4 (RO) Interrupt Vector (RW) TypeCode (RO)
IVO
(RO)
Figure 7-18. The Interrupt Vector Register (IVR)
This chapter having described the features and functions
of the USC that relate to interrupts, this final section will
describe how these features should be used by interrupt
service routines.
7.16.1 Nested Interrupts
An important characteristic of interrupt-driven systems is
whether they allow nested interrupts, that is, whether they
allow interrupt service routines (ISRs) to be themselves
interrupted, or whether each ISR proceeds to completion
before another interrupt can occur.
The USC supports nested interrupts by including an Inter-
rupt Under Service (IUS) latch for each type of interrupt.
When a USC channel that’s requesting an interrupt sees an
interrupt acknowledge cycle and its IEI pin is high, it
automatically sets the IUS latch of the highest priority type
that has its IP bit set. If interrupt acknowledge cycles are
not visible to the USC, software can still allow nested
interrupts by reading the IP bits from the LSbyte of the
DCCR, and explicitly setting the IUS latch of the highest
priority type that has its IP bit set, in the MSbyte of the same
register.
Regardless of whether the IUS bit is set automatically or
explicitly by software, once it’s set the ISR can re-enable
processor interrupts to allow other interrupts. The USC
channel in question will not request another interrupt for
the same type nor any lower-priority type within it, until
software clears the IUS bit near the end of the ISR.
Interrupts from other devices are controlled automatically
if the devices are arranged in an interrupt daisy-chain;
otherwise the central interrupt controller must control which
devices can interrupt which ISRs.
If an ISR re-enables interrupts to allow nested interrupts
from higher-priority types, it’s a good practice to disable
them once again, just before clearing the IUS bit near the
end of the ISR. (They will be enabled again by the standard
mechanism for the processor being used, e.g., an IRET or
RETI instruction, after saved registers are restored from
the stack.) This procedure prevents “tail recursion” when
there’s heavy interrupt traffic, wherein the stack gets filled
with multiple copies of saved registers because another
interrupt of the same type happens as soon as the IUS is
cleared.
7.16.2 Which Type(s) to Handle?
If an interrupt service routine (ISR) is initiated by an
interrupt acknowledge cycle that obtains a vector from the
USC, and the “Vector Incudes Status” option is enabled,
the service routine typically concerns itself only with the
type identified by the vector, and returns from the interrupt
after handling that single type.
Otherwise software should read the Interrupt Pending bits
in the Daisy Chain Control Register (DCCR) to see which
type(s) need service. This is particularly necessary on
IBM-type Personal Computers, in which interrupt acknowl-
edge cycles aren’t visible to add-in peripherals.
If more than one IP bit is set in the DCCR, the ISR may
handle only the most urgent type and return from the
interrupt thereafter, like a “Vector Includes Status” ISR.
Alternatively it may choose to handle all of the types that
have their IP bits set, before returning to the interrupted
process.
Without nested interrupts, worst-case interrupt response
considerations may limit each ISR to handling just one type
of interrupt before re-enabling interrupts and returning to
the interrupted process. This allows the interrupt prioritiz-
ing mechanism to select which interrupt to handle next.
If nested interrupts can occur, it’s more feasible for a USC
ISR to handle all of the pending types within the device
before returning to the interrupted process, because higher-
priority ISRs will be able to run while it’s doing so.
UM009402-0201