Page 85 - The Art of Designing Embedded Systems

72 THE ART OF DESIGNING EMBEDDED SYSTEMS

After 25 years of building embedded systems I’ve learned that long
ISRs are a bad thing, and a symptom of poor code. Keep ’em short, keep
’em simple.

Measuring Performance
In my opinion, the debates about the relative speeds of C versus as-
sembly, or C versus C++, are meaningless. All performance issues are
nothing but a smokescreen unless you’re willing to take qualitative mea-
surements to replace the fog of speculation with the insight of facts.
Amateurs moan and speculate about performance, making random
stabs at optimizing code. Professionals take measurements, only then de-
ciding what action, if any, is appropriate.
If the ISR is not fast enough, your system will fail. Unfortunately,
few of the developers I talk to have any idea what “fast enough” means.
Unless you generate the interrupt map I’ve discussed, only random luck
will save you from speed problems.
When designing the system, answer two questions: how fast is fast
enough? How will you know if you’ve reached this goal?
Some people are born lucky. Not me. I’ve learned that nature is per-
verse and will get me if it can. Call it high-tech paranoia. Plan for prob-
lems, and develop solutions for those problems before they occur. Assume
each ISR will be too slow, and plan accordingly.
A performance analyzer will instantly show the minimum, maxi-
mum, and average execution time required by your code, including your
ISRs (Figure 4-7). There’s no better tool for finding real-time speed issues.

Guesstimating Performance

In 1967 Keuffel & Esser (the greatest of the slide rule companies)
commissioned a study of the future. They predicted that by 2067 we’d see
three-dimensional TVs and cities covered by majestic domes. The study
somehow missed the demise of the slide rule (their main product) within 5
years.
Our need to compute, to routinely deal with numbers, led to the in-
vention of dozens of clever tools, from the abacus to logarithm tables to the
slide rule. All worked in concert with the user’s brain, in an iterative, back-
and-forth process that only slowly produced answers.
Now even grade-school children routinely use graphing calculators.
The device assumes the entire job of computation and sometimes even data
analysis. What a marvel of engineering! Powered by nothing more than a