Page 67 - The Art of Designing Embedded Systems

54 THE ART OF DESIGNING EMBEDDED SYSTEMS

Interrupts

Most embedded systems use at least one or two interrupting devices.
Few designers manage to get their product to market without suffering
metaphorical scars from battling interrupt service routines (ISRs). For
some incomprehensible reason-perhaps because “real time” gets little
more than lip service in academia-most of us leave college without
the slightest idea of how to design, code, and debug these most important
parts of our systems. Too many of us become experts at ISRs the same way
we picked up the secrets of the birds and the bees-from quick conver-
sations in the halls and on the streets with our pals. There’s got to be a
better way!
New developers rail against interrupts because they are difficult to
understand. However, just as we all somehow shattered our parents’ nerves
and learned to drive a stick-shift, it just takes a bit of experience to become
a certified “master of interrupts.”
Before describing the “how,” let’s look at why interrupts are impor-
tant and useful. Somehow peripherals have to tell the CPU that they re-
quire service. On a UART, perhaps a character arrived and is ready inside
the device’s buffer. Maybe a timer counted down and must let the proces-
sor know that an interval has elapsed.
Novice embedded programmers naturally lean toward polled com-
munication. The code simply looks at each device from time to time, ser-
vicing the peripheral if needed. It’s hard to think of a simpler scheme.
An interrupt-serviced device sends a signal to the processor’s dedi-
cated interrupt line. This causes the processor to screech to a stop and in-
voke the device’s unique ISR, which takes care of the peripheral’s needs.
There’s no question that setting up an ISR and associated control registers
is a royal pain. Worse, the smallest mistake causes a major system crash
that’s hard to troubleshoot.
Why, then, not write polled code? The reasons are legion:

1. Polling consumes a lot of CPU horsepower. Whether the periph-
eral is ready for service or not, processor time-usually a lot of
processor time-is spent endlessly asking “Do you need service
yet?”
2. Polled code is generally an unstructured mess. Nearly every loop
and long complex calculation has a call to the polling routines so
that a device’s needs never remain unserviced for long. ISRs, on
the other hand, concentrate all of the code’s involvement with
each device into a single area. Your code is going to be a night-
mare unless you encapsulate hardware-handling routines.