Page 61 - The Art of Designing Embedded Systems

48 THE ART OF DESIGNING EMBEDDED SYSTEMS

there’s always a backup plan, a fall-back position in case something unex-
pected happens.
So, while partitioning by features will not reduce complexity, it leads
to an earlier shipment with less panic as a workable portion of the product
is complete at all times.
In fact, this approach suggests a development strategy that maxi-
mizes the visibility of the product’s quality and schedule.

Develop Firmware Incrementally
Deming showed the world that it’s impossible to test quality into a
product. Software studies further demonstrate the futility of expecting test
to uncover huge numbers of defects in reasonable times-in fact, some
studies show that up to 50% of the code may never be exercised under a
typical test regime.
Yet test is a necessary part of software development.
Firmware testing is dysfunctional and unlikely to be successful when
postponed till the end of the project. The panic to ship overwhelms com-
mon sense; items at the end of the schedule are cut or glossed over. Test is
usually a victim of the panic.
Another weak point of all too many schedules is that nasty line item
known as “integration.” Integration, too, gets deferred to the point where
it’s poorly done.
Yet integration shouldn’t even exist as a line item. Integration im-
plies we’re only fiddling with bits and pieces of the application, ignoring
the problem’s gestalt, until very late in the schedule when an unexpected
problem (unexpected only by people who don’t realize that the reason for
test is to unearth unexpected issues) will be a disaster.
The only reasonable way to build an embedded system is to start in-
tegrating today, now, on the day you first crank a line of code. The biggest
schedule killers are unknowns; only testing and actually running code and
hardware will reveal the existence of these unknowns.
As soon as practicable, build your system’s skeleton and switch it on.
Build the startup code. Get chip selects working. Create stub tasks or call-
ing routines. Glue in purchased packages and prove to yourself that they
work as advertised and as required. Deal with the vendor, if trouble sur-
faces, now rather than in a last-minute debug panic when they’ve unex-
pectedly gone on holiday for a week.
This is a good time to slip in a ROM monitor, perhaps enabled by a
secret command set. It’ll come in handy when you least have time to add