Polled interrupts: how does the CPU know which ISR to run?

  • Thread starter Thread starter eliotsbowe
  • Start date Start date
  • Tags Tags
    cpu
Click For Summary
SUMMARY

This discussion clarifies how CPUs handle polled interrupts, contrasting them with vectored interrupts. In polled interrupts, the CPU determines which Interrupt Service Routine (ISR) to execute by reading an interrupt register that indicates pending interrupts, often utilizing a priority encoder for prioritization. Each device may have a single ISR or multiple ISRs based on interrupt priority levels. The implementation can involve state tracking using switch statements or function pointers in C, ensuring that the correct ISR is executed as device states change.

PREREQUISITES
  • Understanding of Interrupt Service Routines (ISRs)
  • Familiarity with CPU architecture and interrupt registers
  • Knowledge of C programming, particularly switch statements and function pointers
  • Concept of polling versus interrupt-driven I/O
NEXT STEPS
  • Research ARM CPU interrupt handling and single interrupt vector implementation
  • Explore the design and implementation of polling mechanisms in real-time systems
  • Learn about priority encoders and their role in interrupt management
  • Study state machine design patterns in C for managing device states
USEFUL FOR

Embedded systems developers, real-time application programmers, and computer architecture students seeking to deepen their understanding of interrupt handling mechanisms.

eliotsbowe
Messages
34
Reaction score
0
Hello, may someone help me to understand this?
I know that in vectored interrupts, a device asks the CPU to run a certain ISR by sending a specific code. Now, in polled interrupts there's no interrupt vector. So how does the CPU know what's the Interrupt Service Routine to be run?
Perhaps there's only one Interrupt Service Routine per device? Or maybe each device can request one Routine per Interrupt Priority Level, so that the CPU knows what to do just by recognizing the device and the Priority Level of the request?



Thanks a lot for your help.
 
Technology news on Phys.org
eliotsbowe said:
So how does the CPU know what's the Interrupt Service Routine to be run?
Depends on the CPU and the related hardware. Generally there will be an interrupt register to indicate which interrupts are pending. The interrrupt register could use a separate bit for each possible interrupt, or the hardware could have a priority encoder that returns a value representing the highest priority pending interrupt.

For polled interrupts, the CPU won't know which interrupt to run, instead the code will have to determine which interrupt to run based on the interrupt register contents. In addition, each interrupt handler may be keeping track of the "state" of a device, in order to decide which code segment should be used to handle the current interrupt as a device goes thorugh a series of states. In C, this can be done with a switch variable and switch / case statement or one or more pointers to functions and calls via those pointers to functions, where the switch variable or pointers to function are updated as the state of a device changes.

Even when using hardware interrupts, some CPUs, such as the ARM, only have a single interrupt vector (there's also another fast interrupt vector), so the code has to read an interrupt register to determine which routine to call even when using interrupts instead of polling.
 
Last edited:
got it, thanks!
 
It is possible to simulate interrupts using "polling", which is basically a loop. Each time through the loop, the code looks down through a series of options and acts on the ones that need attention. When writing real-time code, polling has the advantage of allowing a programmer to know EXACTLY what the worst-case time for the loop will be. However, it takes a great deal of patience, planning and care to design.

I used to write code for lightwave systems at Bell Labs. Polling was the only way we could guarantee that everything would always get handled withing the required tolerances. But it was hard for some programmers to wrap their heads around it. We had about 5 different Motorola 68000 processors; they communicated with each other using shared memory, all by polling (no locking!). Each memory location could only be written by one processor, and the others could only read from that location. The readers would "debounce" (read multiple times, to see if changes occurred) before using new values.

The entire scheme was simple and did not involve operating system calls or hardware interrupts.
 

Similar threads

Replies
6
Views
4K
Replies
7
Views
2K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 11 ·
Replies
11
Views
6K
  • · Replies 8 ·
Replies
8
Views
2K
  • Sticky
  • · Replies 13 ·
Replies
13
Views
8K
Replies
7
Views
3K
  • · Replies 30 ·
2
Replies
30
Views
3K
Replies
4
Views
2K