Interrupt Controller

From COMP15212 Wiki
Revision as of 10:52, 1 August 2019 by pc>Yuron
Depends on Interrupt Service Routine

Many interrupts may be requesting services at the same time. Any particular processor must pick (at most!) one service routine at once. This is usually prioritised because some interrupts are more urgent than others and the interrupt latency may be important – particularly but not exclusively in real time environments. An interrupt controller is a hardware device which supports this process.

Excuse the hardware diagram: it is appropriate to illustrate operation in this case.

Interrupt controller

The interrupt controller will have many input signals from various I/O devices. Some of these may not be wanted by the O.S. and others may want to be disabled some of the time; thus there is usually a layer of programmable enable bits – one per input signal.

Inputs will then be assigned a priority; this is typically programmable, so each signal may have an associated priority field. In this figure a larger number indicates a higher priority.

Only interrupts which are active and enabled are considered at any time. The highest priority, active, enabled interrupt (if there is one) will go forward. If (and only if) this is of a higher priority than the current operating priority will the controller attempt to interrupt the processor.

If the processor accepts the interrupt the vector is read and, simultaneously, the priority of the controller is raised. The previous priority is stacked so that it can be resumed when the new ISR is complete.



Articles on IO
Cacheability • Device Drivers • Direct Memory Access (DMA) • IO • Interprocess Communication • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Libraries • Peripheral devices • Pipes • Queues • Queues Extra • Resources • Shell • Sockets • Spooling and Buffering • Starvation • Streams • System Calls • Thrashing • Timers • Using Peripherals • Virtualisation • Write Buffer