Page 103 - The Art of Designing Embedded Systems

90 THE ART OF DESIGNING EMBEDDED SYSTEMS

did, before you move on to receiving. Segment the problem to keep things
simple.
If only we could live with simple programmed inputs and outputs!
Most nontrivial peripherals will operate in an interrupt-driven mode. Add
ISRs, one at a time, testing each one, for each part of the device. For ex-
ample, with the UART, completely master interrupt-driven transmission
before moving on to interrupting reception.
Again, with each small success immediately create, compile, and test
code before you’ve forgotten the tricks required to make the little beast op-
erate properly. Databooks are cornucopias of information and misinfor-
mation; it’s astonishing how often you’ll find a bit documented incorrectly.
Don’t rely on frail memory to preserve this information. Mark up the book,
create and test the code, and move on.
Some devices are simply too complex to yield to manual testing. An
Ethernet driver or an IEEE-488 port both require so much setup that there’s
no choice but to initially write a lot of code to preset each internal register.
These are the most frustrating sorts of devices to handle, as all too often
there’s little diagnostic feedback-you set a zillion registers, burn some in-
cense, and hope it flies.
If your driver will transfer data using DMA, it still makes sense to
first figure out how to use it a byte at a time in a programmed VO mode.
Be lazy-it’s just too hard to master the DMA, interrupt completion rou-
tines, and the part itself all at once. Get single-byte transfers working be-
fore opening the Pandora’s box of DMA.
In the “make it work’ phase we usually succumb to temptation and
hack away at the code, changing bits just to see what happens. The docu-
mentation generally suffers. Leave a bit of time before wrapping up each
completed routine to tune the comments. It’s a lot easier to do this when
you still remember what happened and why.
More than once I’ve found that the code developed this way is ugly.
Downright lousy, in fact, as coding discipline flew out the window during
the bit-tweaking frenzy. The entire point of this effort is to master the de-
vice (first) and create a driver (second). Be willing to toss the code and
build a less offensive second iteration. Test that too, before moving on.

Selecting Stack Size
With experience, one learns the standard, scientific way to compute
the proper size for a stack Pick a size at random and hope.
Unhappily. if your guess is too small the system will erratically and