Page 68 - The Art of Designing Embedded Systems

Real Time Means Right Now! 55

3. Polling leads to highly variable latency. If the code is busy han-
dling something else (just doing a floating-point add on an 8-bit
CPU might cost hundreds of microseconds), the device is ignored.
Properly managed interrupts can result in predictable latencies of
no more than a handful of microseconds.

Use an ISR pretty much any time a device can asynchronously re-
quire service. I say “pretty much” because there are exceptions. As we’ll
see, interrupts impose their own sometimes unacceptable latencies and
overhead. I did a tape interface once, assuming the processor was fast
enough to handle each incoming byte via an interrupt. Nope. Only polling
worked. In fact. tuning the five instruction polling loops‘ speed ate up 3
weeks of development time.

Vectvring
Though interrupt schemes vary widely from processor to processor,
most modem chips use a variation of vectoring. Peripherals, whether ex-
ternal to the chip or internal (such as on-board timers), assert the CPU’s in-
terrupt input.
The processor generally completes the current instruction and stores
the processor’s state (current program counter and possibly flag register)
on the stack. The entire rationale behind ISRs is to accept, service, and re-
turn from the interrupt, all with no visible impact on the code. This is pos-
sible only if the hardware and software save the system’s context before
branching to the ISR.
It then acknowledges the interrupt, issuing a unique interrupt ac-
knowledge cycle recognized by the interrupting hardware. During this
cycle the device places an interrupt code on the data bus that tells the
processor where to find the associated vector in memory.
Now the CPU interprets the vector and creates a pointer to the inter-
rupt vector table, a set of ISR addresses stored in memory, It reads the ad-
dress and branches to the ISR.
Once the ISR starts, you, the programmer, must preserve the CPU’s
context (such as saving registers, restoring them before exiting). The ISR
does whatever it must, then returns with all registers intact to the normal
program flow. The main-line application never knows that the interrupt
occurred.
Figures 4- 1 and 4-2 show two views of how an x86 processor handles
an interrupt. When the interrupt request line goes high, the CPU completes
the instruction it’s executing (in this case at address 0100) and pushes the