Interrupt Controller: Difference between revisions
pc>Yuron No edit summary |
 W81054ch [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{#set: Priority=1 | Summary=A hardware device used to assist the rapid dispatch to an appropriate interrupt service routine.}}<!-- | {{#set: Priority=1 | Summary=A hardware device used to assist the rapid dispatch to an appropriate interrupt service routine.}}<!-- | ||
-->{{#invoke:Dependencies|add|Interrupt Service Routine,3}} | -->{{#invoke:Dependencies|add|Interrupt Service Routine,3}} | ||
Many interrupts may be requesting services at the same time. Any | Many interrupts may be requesting services at the same time. Any particular processor must pick (at most!) one [[Interrupt_Service_Routine|service routine]] at once. This is usually <em>prioritised</em> because some interrupts are more urgent than others and the [https://en.wikipedia.org/wiki/Interrupt_latency interrupt latency] may be important – particularly but not exclusively in [[Real_Time|real time]] environments. An interrupt controller is a hardware device which supports this process. | ||
particular processor must pick (at most!) one [[Interrupt_Service_Routine|service | |||
routine]] at once. This is usually | |||
<em>prioritised</em> because some interrupts are more urgent than others and | |||
the [https://en.wikipedia.org/wiki/Interrupt_latency interrupt latency] may be | |||
important – particularly but not exclusively in [[Real_Time|real time]] environments. An interrupt controller is a hardware device which supports this process. | |||
<blockquote> | <blockquote> | ||
Excuse the hardware diagram: it is appropriate to illustrate | Excuse the hardware diagram: it is appropriate to illustrate operation in this case. | ||
operation in this case. | |||
</blockquote> | </blockquote> | ||
[[Image:interrupt_controller.png|link=|alt=Interrupt controller]] | [[Image:interrupt_controller.png|link=|alt=Interrupt controller]] | ||
The interrupt controller will have <em>many</em> input signals from various | The interrupt controller will have <em>many</em> 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 <strong>enable</strong> bits – one per input signal. | ||
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 <strong>enable</strong> bits – one per input signal. | |||
Inputs will then be assigned a <strong>priority</strong>; this is typically | Inputs will then be assigned a <strong>priority</strong>; this is typically programmable, so each signal may have an associated priority field. In this figure a larger number indicates a higher priority. | ||
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 | 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 <em>higher</em> priority than the current operating priority will the controller attempt to interrupt the processor. | ||
time. The highest priority, active, enabled interrupt (if there is | |||
one) will go forward. If (and only if) this is of a <em>higher</em> priority | |||
than the current operating priority will the controller attempt to | |||
interrupt the processor. | |||
If the processor accepts the interrupt the <strong>vector</strong> is read and, | If the processor accepts the interrupt the <strong>vector</strong> is read and, simultaneously, the priority of the controller is raised. The previous priority is <em>stacked</em> so that it can be resumed when the new ISR is complete. | ||
simultaneously, the priority of the controller is raised. The | |||
previous priority is <em>stacked</em> so that it can be resumed when the new | |||
ISR is complete. | |||
---- | ---- | ||
Latest revision as of 10:03, 5 August 2019
| 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.
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.
