With most embedded systems, many bad problems lie inside "the box"
Scott Rosenthal
April, 1997
I just returned from an extended weekend in London with a good friend. Being engineers,
and appreciating the march of technology over the centuries, we made a beeline for the
British Museum. For readers not familiar with that establishment, it's the repository for
a tremendous number of artifacts covering more than just the history of England and its
empire. During the height of the empire in the 18th and 19th centuries, British merchants
and warships brought back just about anything that wasn't nailed down. The loot ranges
from Egyptian mummies to entire Greek temples. In addition, the British Museum also houses
the manuscripts, literature and music that have defined not only the English-speaking
world, but also a good portion of science and technology.
After exploring one small section, we settled back at the Museum Pub to reflect on the
many millennia of innovation we had just breezed through. After a few pints, it became
clear that over the ages the march of technology was beset with as many difficulties,
prejudices and "not invented here" attitudes as any of the projects I've ever
been involved with. Regardless of the era, engineering consists of two parts: defining the
problem and finding a solution. Many times the answer lies not in plowing through a known
approach but in taking a step back, turning the problem on its ear and finding another
way. What I saw in the British Museum was amazingly relevant to the problems I face every
day in embedded design.
Historical boxes
As I wandered around and listened to tour guides, one thing became very
apparent—technological solutions throughout the ages occurred when people stepped
outside their mental boxes and viewed a problem from a different perspective. For example,
the museum owns an original Gutenberg Bible. We think of Gutenberg as inventing the
printing press, whereas people had actually been printing for almost a thousand years
before him. In the seventh century AD, a Chinese emperor printed one million scrolls and
sent them throughout his country.
What Gutenberg did was to view the problem from a different perspective. Before him,
printing involved making a reversible image of an entire page, each requiring a different
image. In today's vernacular, Gutenberg's breakthrough was to invent OOP (object-oriented
printing). He recognized that what actually appears on paper isn't a page but instead is
the collected instantiations of a class called letters. The letter class, in turn, had
properties (equal heights with variable widths) and methods (how to keep all the raised
type at the same height for printing). What he found was a way to inexpensively produce
books by reusing the components of each book (like my search for the reusable software
module).
However, even Gutenberg had a mental box to contend with. In his day, monks would
laboriously illuminate manuscripts with fancy drawings and designs. When he started
printing his famous Bible, Gutenberg was determined that the book should look like a
manuscript—including the illuminations. This unfortunate design decision limited his
process’ throughput to that of the artisans hand painting the illustrations on every
printed copy. It took another 50 years before someone got outside that box and printed
(without illuminations) what we’d today call a book.
Another example of such thinking I came across at the museum was the Rosetta stone.
It's fascinating how long it took to decipher the hieroglyphics. You’d think it
would've been easy with the Greek text as a guide. Again, people were stuck in their
boxes. At that time, scholars assumed that the hieroglyphics were pictorial metaphors as
in Chinese. It took more than 20 years before two scholars stepped outside the box and
discovered that the hieroglyphics represent an alphabet of sounds, much like our present
alphabet. With this new insight, they unraveled the mystery of the Rosetta stone,
hieroglyphics and ancient Egyptian culture.
Today's boxes
What makes the foregoing discussion something more than just an intellectual exercise
is that the boxes we face in embedded design aren't really all that different from those
examples. We constantly bump up against people telling us, "we've always done it that
way", "there's no other way" or "just because." Yet, for us to be
better designers, we constantly need to be on guard against getting stuck in our boxes.
Your boss and company depend on you to produce products better, cheaper and faster.
Drawing on personal experiences of thinking "outside the box," I once worked
on an optical device to track and test peoples’ eyes. Part of the test required a
bright light that constricts the test subject's pupil. An optical engineer designed an
elaborate system that evenly illuminated the eye's field of view. It worked great, but the
expense and complexity were far beyond what we could afford.
Then I stepped back and rethought the problem. I replaced all the lenses and other
optical paraphernalia with half a tennis ball. To turn the ball into an optical device I
cut it in half, painted it white, put an LED inside and covered the opening with a white
translucent material. The LED shines into the tennis ball and light reflects back to the
screen, illuminating it with an even intensity.
Although this prototype worked great (and cost next to nothing), I couldn't ship
product to the client with cut-up tennis balls inside. Illustrating the wondrous insights
a free-ranging mind can produce, I then remembered the breast pump my wife used when
nursing our last child. The pump's hemispheric top was the perfect size and shape for my
light source. So I turned on my home oven and heated some Plexiglas until it began to get
soft; then I used the pump's sucking action to form a Plexiglas hemisphere using the top
of the pump as a mold. The result was a professional-looking, economical and
easy-to-produce dome for the light source.
As another example, recall my two previous columns about adding speech output to an
embedded design. Sure, speech-processing chips, audio chips or other specialized sound
makers work, but you can also add this capability with just a processor.
In a related issue there's an interesting debate going on in the embedded newsgroup
regarding assembly language and C. It seems as though a few die-hards insist that the only
true embedded system is one based on assembly language. They’re stuck in a box! No
customer, consumer or user really cares which "language" is in a system. Think
about it—when was the last time you saw a Cadillac ad bragging about how well its ABS
works because the engineers programmed it in C?
A language is just a tool, and you should always use the right one for the job.
Although I spent the first 13 years of my career writing assembly code for embedded
systems, for the past 11 years my code has been primarily C with a touch of assembly when
necessary. Even though I’m a purist with some things, writing code is just a means to
ship a product. If the product meets the end user's needs in terms of functionality and
cost, then I've done my job and the language is immaterial.
It's only by giving up our preconceived ideas and prejudices and focusing on real
problems that we can solve the thousands of problems constantly encountered in embedded
design. Solutions come from everywhere as long as we’re receptive to them.
Moving on…
For the past six years, Assoc. Editor Mike Porter has edited these columns, a task that
alternately meant prodding me when I didn't have ideas, sharing tales of woe and fun, and
encouraging me to contribute. Because of his positive and constructive input, he was able
to bring out in me a writing skill I never knew existed. Mike is leaving the magazine, so
I’d like to say thanks for the gift and wish him luck in all future endeavors. PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
