Page 90 - The Art of Designing Embedded Systems

Real Time Means Right Now! 77

A simple CPU has very predictable timing. Add a prefetcher or
pipeline and timing gets fuzzier, but still is easy to figure within 10 or 20%.
Cache is the wildcard, and as cache size increases, determinism dimin-
ishes. Thankfully, today few small embedded CPUs have even the small-
est amount of cache.
Your first weapon in the performance arsenal is developing an un-
derstanding of the target processor. What can it do in one microsecond?
One instruction? Five? Some developers use very, very slow clocks when
not much has to happen-ne outfit I know runs the CPU (in a spacecraft)
at 8 kHz until real speed is needed. At 8 kHz they get maybe 1000 in-
structions per second. Even small loops become a serious problem. Un-
derstanding the physics-a perhaps fuzzy knowledge of just what the CPU
can do at this clock rate-means the big decisions are easy to make.
Estimation is one of engineering’s most important tools. Do you
think the architect designing a house does a finite element analysis to fig-
ure the size of the joists? No! He refers to a manual of standards. A 15-foot
unsupported span typically uses joists of a certain size. These estimates.
backed up with practical experience, ensure that a design, while perhaps
not optimum, is adequate.
We do the same in hardware engineering. Electrons travel at about
one or two feet per nanosecond, depending on the conductor. It’s hard to
make high-frequency first harmonic crystals, so use a higher order har-
monic. Very small PCB tracks are difficult to manufacture reliably. All of
these are ingredients of the “practice” of the art of hardware design. None
of these are tremendously accurate: you can, after all, create one-mil tracks
on a board for a ton of money. The exact parameters are fuzzy, but the gen-
eral guidelines are indeed correct.
So, too, for software engineering. We need to develop a sense of the
art. A 68HC16, at 16 MHz, runs so many instructions per second (plus or
minus). With this particular compiler you can expect (more or less) this
sort of performance under these conditions.
Data, even fuzzy data, lets us bound our decisions, greatly improving
the chances of success. The alternative is to spend months and years gen-
erating a mathematically precise solution-which we won’t do--or to bum
incense and pray . . . the usual approach.
Experiment. Run portions of the code. Use a stopwatch-metaphor-
ical or otherwise-to see how it executes. Buy a performance analyzer or
simply instrument sections of the firmware to understand the code’s per-
formance.
The first time you do this you’ll think, “This is so cool,” and you’ll
walk away with a clear number: xxx microseconds for this routine. With