Page 71 - The Art of Designing Embedded Systems

58 THE ART OF DESIGNING EMBEDDED SYSTEMS

Latency Max-time Freq Description

lNTl 1 OOOusec 1 OOOusec timer
I NT2 1 OOusec 1 OOusec send data
I NT3 250usec 250usec Serial data in
I NT4 15usec 1 OOusec write tape
NMI 200usec 5OOusec once! System crash
FIGURE 4-3 An interrupt map.

degree of flexibility (spend too much on dinner this month and, assuming
you don’t abuse the credit cards, you’ll have to reduce spending some-
where else). Like any budget, it’s a condensed view of a profound reality
whose parameters your system must meet. One number only is cast in
stone: there’s only one second’s worth of compute time per second to get
everything done. You can tune execution time of any ISR, but be sure
there’s enough time overall to handle every device.
Approximate the complexity of each ISR. Given the interrupt rate,
with some idea of how long it’ll take to service each, you can assign pri-
orities (assuming your hardware includes some sort of interrupt controller).
Give the highest priority to things that must be done in staggeringly short
times to satisfy the hardware or the system’s mission (such as to accept
data coming in from a 1 Mb/sec source).
The cardinal rule of ISRs is to keep the handlers short. A long ISR
simply reduces the odds you’ll be able to handle all time-critical events in
a timely fashion. If the interrupt starts something truly complex, have the
ISR spawn off a task that can run independently. This is an area where an
RTOS is a real asset, as task management requires nothing more than a call
from the application code.
Short, of course, is measured in time, not in code size. Avoid loops.
Avoid long complex instructions (repeating moves, hideous math, and the
like). Think like an optimizing compiler: does this code really need to be
in the ISR? Can you move it out of the ISR into some less critical section
of code?
For example, if an interrupt source maintains a time-of-day clock,
simply accept the interrupt and increment a counter. Then return. Let some
other chunk of code-perhaps a non-real-time task spawned from the
ISR-worry about converting counts to time and day of the week.
Ditto for command processing. I see lots of systems where an ISR re-
ceives a stream of serial data, queues it to RAM, and then executes com-
mands or otherwise processes the data. Bad idea! The ISR should simply
queue the data. If time is really pressing &e., you need real-time response