Page 80 - The Art of Designing Embedded Systems

Real Time Means Right Now! 67

Most of these sorts of difficulties stem from slow ISRs, or from code
that leaves interrupts off for too long. Be wary of any code that executes a
disable-interrupt instruction. There’s rarely a good reason for it; this is
usually an indication of sloppy software.
It’s rather difficult to find a chunk of code that leaves interrupts off.
The ancient 8080 had a wonderful pin that showed interrupt state all of the
time. It was easy to watch this on the scope and look for interrupts that
came during that period. Now, having advanced so far, we have no such
easy troubleshooting aids. About the best one can do is watch the INTR
pin. If it stays asserted for long periods of time, and if it’s properly de-
signed (i.e., stays asserted until INTA), then interrupts are certainly off.
One design rule of thumb will help minimize missing interrupts:
reenable interrupts in ISRs at the earliest safe spot.

Reentrancy Problems

Well-designed interrupt handlers are largely reentrant. Reentrant
functions-a.k.a. “pure code”-are often falsely thought to be any code
that does not modify itself. Too many programmers feel that if they sim-
ply avoid self-modifying code, their routines are guaranteed to be reen-
trant, and thus interrupt-safe. Nothing could be further from the truth.
A function is reentrant if, while it is being executed, it can be rein-
voked by itself, or by any other routine.
Suppose your main-line routine and the ISRs are all coded in C. The
compiler will certainly invoke runtime functions to support floating-point
math, VO, string manipulations, etc. If the runtime package is only par-
tially reentrant, then your ISRs may very well corrupt the execution of the
main line code. This problem is common, but is virtually impossible to
troubleshoot, since symptoms result only occasionally and erratically.
There’s nothing more ulcer-inducing than isolating a bug that manifests it-
self only occasionally, and with totally different characteristics each time.
Sometimes we’re tempted to cheat and write a nearly pure routine. If
your ISR merely increments a global 32-bit value, maybe to maintain time,
it would seem legal to produce code that does nothing more than a quick
and dirty increment. Beware! Especially when writing code on an 8- or 16-
bit processor, remember that the C compiler will surely generate several
instructions to do the deed. On a 186, the construct ++j might produce

mov ax, [jl
add ax,l ; increment low part of j
mov [jl ,ax