Page 91 - The Art of Designing Embedded Systems

78 THE ART OF DESIGNING EMBEDDED SYSTEMS

time you’ll develop a sense of speed. “You know, integer compares are
pretty damn fast on this system.” Later-as you develop a sense of the
art-you’ll be able to bound things. “Nah, there’s no way that loop can
complete in 50 microseconds.”
This is called experience, something that we all too often acquire
haphazardly. We plan our financial future, we work daily with our kids on
their homework, even remember to service the lawnmower at the begin-
ning of the season, yet neglect to proactively improve our abilities at work.
Experience comes from exposure to problems and from learning
from them. A fast, useful sort of performance expertise comes from ex-
trapolating from a current product to the next. Most of us work for a com-
pany that generally sells a series of similar products. When it’s time to
design a new one, we draw from the experience of the last, and from the
code and design base. Building version 2.0 of a widget? Surely you’ll use
algorithms and ideas from 1.0. Use 1.0 as a testbed. Gather performance
data by instrumenting the code.
Always close the feedback loop! When any project is complete,
spend a day learning about what you did. Measure the performance of the
system to see just how accurate your processor utilization estimates were.
The results are always interesting and sometimes terrifying. If, as is often
the case, the numbers bear little resemblance to the original goals, then fig-
ure out what happened, and use this information to improve your estimat-
ing ability. Without feedback, you work forever in the dark. Strive to learn
from your successes as well as your failures.
Track your system’s performance all during the project’s develop-
ment, so you’re not presented with a disaster two weeks before the sched-
uled delivery. It’s not a bad idea to assign CPU utilization specifications to
major routines during overall design, and then track these targets as you do
the schedule. Avoid surprises with careful planning.
A lot of projects eventually get into trouble by overloading the
processor. This is always discovered late in the development, during de-
bugging or final integration, when the cost of correcting the problem is at
the maximum. Then a mad scramble to remove machine cycles begins.
We all know the old adage that 80% of the processor burden lies in
20% of the code. It’s important to find and optimize that 20%, not some
other section that will have little impact on the system’s overall per-
formance. Nothing is worse than spending a week optimizing the wrong
routine!
If you understand the design, if you have a sense of the CPU. you’ll
know where that 20% of the code is before you write a line. Knowledge is
power.