In The Trenches
subroutines must be smarter than you.
Let’s look at two concrete examples. The first concerns a major ASIC
(Application Specific Integrated
Circuit) manufacturer. A number of
years ago, I used ASICs, which can be
thought of as consisting of a large
number of small programmable logic
devices with a fixed number of programmable interconnections. I had
been developing these “by hand.”
That is, I would define the logic and
figure out the best way to interconnect
them by myself. But, as the ASICs got
more and more dense, developing
them by hand became unworkable.
I bought very expensive development software that would design an
ASIC from a schematic diagram. At
the training class, I noticed that if a
flip-flop wasn’t using the “Reset” function, it was shown as grounded in the
schematic. This was odd because the
flip-flop logic could be configured
without a reset at all. Grounding it
wasted an input to the logic device, as
well as wasting interconnect resources
to wire it to ground. Overall, this resulted in wasting about 10% to 20% of
the ASIC. Therefore, anyone who
employed this tool without understanding its implications could never
fully use the power of the ASIC.
A potentially more serious example is with Anti-lock Braking Systems
(ABS) on cars and trucks. Here, a
computer detects when the wheels
stop turning and briefly releases the
brakes in order to prevent a skid. It
sounds great and works pretty well
most of the time.
With ABS, a good driver can generally come to a stop in about 10% less
distance on dry pavement. However, on
newly fallen snow, dirt roads, and some
gravel roads ABS works very poorly.
The stopping distance in increased by
100% to 200% over that of a good driver, because on these roads, you want
the wheels to lock up. In lock-up, the
snow, dirt, or gravel builds up in front of
the tire and acts like a wedge or wheel
chock. With ABS, the vehicle just rolls
and rolls and rolls. You don’t skid, but
you don’t stop, either.
There are software products to
automatically create websites. There
are products that write interface code
for you. There are products that claim
to make everyone in the department
an expert. Some are good, and some
aren’t. All of them make every user
equal. Unfortunately, this equality —
whether it’s ASIC design or web-page
layout or something else — is rarely
better than average. And if everyone is
an “expert,” then no one is. Besides,
do you really want to rely on someone
else to do your work for you?
Note that I am not against
progress or new approaches. I appreciate novel ideas and products that
save me time. It’s critical, however, to
maintain control of every aspect of a
project. It’s hard to believe that some
stranger thousands of miles away
knows my project better than I do. I
also enjoy thinking for myself.
Lastly, by using pre-developed
software products, you are helpless if
anything goes wrong with that part of
the project. If you didn’t know how to
design it to begin with, how can you
fix it? Control, experience, and training are elements of a project for
which the designer is responsible.
You can’t get these out of a box, any
more than you can take a pill as a
substitute for exercise.
The need for self-test routines for
any hardware interface can’t be overstated. If there is a bad component, it is
critical to know this before trying to execute any instructions. With a jammed
motor or a faulty sensor, the program
can be a menace to lives and property.
Developing self-test code doesn’t
have to be difficult. If you’ve been writing test code as you developed the software, most of the work is already done.
All you have to do is assemble the
modules into a logical framework. (Can
anyone say bottom-up programming?)
Of course, if you plan to use these test
routines from the start, you can make
the assembly effort easier still.
One important point often ignored
is to make your error messages clear,
and simple enough to be understood
by anyone. There is nothing more frustrating than getting a cryptic error message that makes no sense. Tracking
down the documentation isn’t always
easy. For clarity, use the best available
means that your hardware provides.
Another use for self-test routines
is in production. Most self-test code
measures some aspect of the hardware. Often this is useful to know during the fabrication of the product, as it
NanoCore12™ for best performance and price!
9S12C microcontroller modules starting at $45!
i -co patible w p n m ith BASIC Sta mm p2® O m E (1K): fro $23 SMingle: fro $45
(USA & Canada)
™NanoCore12 is a trademark of Technological Arts, Inc.
® BASIC Stamp is a registered trademark of Parallax, Inc.
• on-board RS232C interface
• up to 33 I/O lines, with multi-property programmability
(e.g. direction, pull-up/pull-down,
reduced drive, invert polarity, etc.)
• up to 8 key wake-up interrupt
inputs, with digital filtering
• SCI • SPI • CAN
• 8-channel 10-bit ADCs
• multiple PWM channels
• 4-channel timers, supporting
input capture/output compare,
event counting, gated time
accumulation, and simple PWM
• 32K multi-sector Flash • 2K RAM
• operates up to 48MHz via PLL
• 3. 3 V or 5 V operation
• advanced CISC architecture
• on-chip Serial Monitor
• supports BDM debugging