Electronic – Polling vs Interrupt: which one is first in a bare-bone piece of hardware

interruptsmicroprocessor

First of all, I must say that I have a computer science background, and I don't have much knowledge about hardware. I would like to ask this question because in software, what I often see is a loop, e.g: while loop, for…loop…

In my understanding, polling is like you check for an event occur every certain amount of time (might require the use of clock?)

Interrupt is like we don't care if it "loops" or not, when the event comes, it will "signal"…

What about in hardware? What is actually equivalent to a "while loop" or "for loop" in hardware? I assume it is a mix of polling and interrupts…but I wonder which one is really first? Isn't it it that when we check for something, we must poll it first? (maybe I'm a bit biased on polling here).

Best Answer

Something to know is that interrupts require special hardware to work, and work at a layer 'outside' what you can manage purely with a programming language like C. Typically different compilers and different chips expose interrupt controls in different ways. Some have magical function names, or magical preprocessor macros, that signal the compiler to use the special instructions and memory layouts that are needed to manage the interrupts.

In the case of polling, the software running has some loops, checks some value, then branches when the state of interest has been reached. This is the normal programming you are familiar with.

With an interrupt, the chip has hardware to halt execution of the software, and jump to a special location for the interrupt handler. The interrupt handler often needs to save the state of the halted software, so that after the handler does its job, it can return to the software and pick up where it left off.

Neither method is "first", and while the interrupt style of programming can make some applications considerably faster, virtually any application can be written to use either method. Different applications are better suited to one or the other.

Related Solutions

Electronic – How interrupts handle does work on a physical layer

The details depend entirely on the CPU, so you're best to pick your favorite CPU and study it in detail. For more general knowledge, there are books on computer architectures, like those by William Stallings.

In one of the simplest, traditional designs, the CPU simply does not "know" at all which device interrupted it. The CPU has a single interrupt line. If there are multiple devices, they are all tied to that single line: for instance, with a big OR gate. When the CPU handles the interrupt, the top level of the interrupt handling routine has to interrogate all of the devices by peeking at their respective status registers, to determine which one, or which ones, require service. When they are properly dealt with, they de-assert the interrupt signal. Blocking specific interrupts can be implemented by making the external circuit sophisticated so that it can be programmed to selectively ignore some of its inputs.

This design can be improved upon in a myriad ways. For instance, there can be protocols whereby an interrupting device has to invoke a special bus cycle, and place its ID (8 bits or whatever) on the data bus, such that the CPU picks it up. The ID can then be used to index into an interrupt vector to dispatch an appropriate interrupt.

A processor doesn't even have to have interrupt pins; in one possible design, an interrupt is simulated when a device makes a write to some special memory location. Effectively, the address and data pins of the CPU serve as the interrupt inputs. See Message Signaled Interrupts.

Electronic – Is USB UHCI polling-based or interrupt driven

The key point is that normally, the interrupt transfers are not considered complete until some data is received. beyondLogic's great USB protocol docs say:

If an interrupt has been queued by the device, the function will send a data packet containing data relevant to the interrupt when it receives the IN Token. [...] If on the other hand an interrupt condition was not present when the host polled the interrupt endpoint with an IN token, then the function signals this state by sending a NAK.

For your specific controller, the table on page 22 in your doc talks about retry counter in 28:27. If you look at the table, you'd notice that "NAK received" does not decrement it! So as long as you set at least one retry, the controller will retry indefinitely on NAKs, without bothering the host.

But there is a much simpler way to check this -- find any Linux system with USB keyboard, and check the interrupt counter:

watch -d -n 0.5 cat /proc/interrupts

On my system, there is a line which says "IR-PCI-MSI 327680-edge xhci_hcd", and it has non-changing number if I am not touching mouse or keyboard. Moving the mouse causes this number to increase. So this is clearly interrupt based.

Best Answer

Related Solutions

Electronic – How interrupts handle does work on a physical layer

Electronic – Is USB UHCI polling-based or interrupt driven

Related Topic