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

  • Thread starter Thread starter eliotsbowe
  • Start date Start date
  • Tags Tags
    cpu
AI Thread Summary
In polled interrupts, the CPU determines which Interrupt Service Routine (ISR) to execute by checking an interrupt register that indicates pending interrupts. Unlike vectored interrupts, there is no specific code sent by devices; instead, the CPU relies on the state of the devices and their priority levels to identify the appropriate ISR. Each device may have a single ISR or multiple ISRs based on priority levels, and the code must manage device states to decide which routine to call. Polling can be advantageous in real-time systems, allowing precise control over timing, though it requires careful design and implementation. Overall, understanding the mechanics of polling and interrupt handling is crucial for effective system programming.
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.
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Back
Top