Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

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

  1. Feb 20, 2013 #1
    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.
  2. jcsd
  3. Feb 20, 2013 #2


    Staff: Mentor

  4. Feb 20, 2013 #3


    User Avatar
    Homework Helper

    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: Feb 20, 2013
  5. Feb 22, 2013 #4
    got it, thanks!
  6. Mar 6, 2013 #5


    User Avatar
    Gold Member

    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.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook