Page 101 - The Art of Designing Embedded Systems

88 THE ART OF DESIGNING EMBEDDED SYSTEMS

Next, create a single, operating, interrupt service routine. You’re
going to have to do this sooner or later anyway; swallow the bitter pill up
front.
Identify every hardware device that needs a driver. This may even
include memory, where (as with Flash) your code must do something
to make it operate. Make a list, check it twice-LEDs, displays, timers,
serial channels, DMA, communications controllers-include each com-
ponent.
Surely you’ll use a driver for each, though in some cases the driver
may be segmented into several hunks of code, such as a couple of ISRs, a
queue handler, and the like.
Next, set up a test environment for fiddling with the hardware. Use an
emulator, a ROM monitor, or any tool that lets you start and stop the code.
Manually exercise the ports (issue inputs and outputs to the device).
Gain mastery of each component by making it do something. Don’t
write code at this point-use your tool’s input/output commands. If the
port is a stack of LEDs, figure out how to toggle each one on and off. It’s
kind of fun, actually, to watch your machinations affect the hardware!
This is the time to develop a deep understanding of the device. All
too often the documentation will be incomplete or just plain wrong. Bits
inverted and transposed. Incorrect register addresses. You’ll never find
these problems via the normal design-code-inspect-debug cycle. Only
playing with the devices-hacking !-with a decent debugging tool will
unveil the peripheral’s mysteries.
If you can’t speak the hardware lingo, working with a part that has
100 “easy-to-set-up” registers will be impossible. If you are a hardware ex-
pert, dealing with these complex parts is merely a nightmare. Count on
agony when the databook for a lousy timer weighs a couple of pounds.
Adopt a philosophy of creating a stimulus, then measuring the sys-
tem’s response with an appropriate tool.
Figures 5-1 and 5-2 illustrate this principle. The debugger’s (in this
case, driving an emulator) low-level commands configure the timer inside
a 386EX. The response, measured on a scope, shows how the timer be-
haves with the indicated setup.
Using a serial port? Connect a terminal and learn how to transmit a
single character. Again, manually set up the registers (carefully docu-
menting what you did), using parameters extracted from the databook,
using the tool’s output command to send characters. Lots of things can go
wrong with something as complicated as a UART, so I like to instrument
its output with a scope. If the baud rate is incorrect, a terminal will merely
display scrambled garbage; the scope will clearly show the problem.