SLTF Consulting
Technology with Business Sense



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

Copyright © 1998-2012 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.