Copyright 1994, Jack G. Ganssle

Abstract

We electronics people are the last to take advantage of the miracles we create. It's time the embedded designers of the world get into the Internet to start communicating more, and not working so damn hard!

Published in Embedded Systems Programming, December 1994

On the way from my hometown of Columbia, MD to California for this year's Embedded Systems Conference I stopped for a few days in Charleston, SC to see some friends off in the BOC Single-handed Around the World sailing race. With the racers finally on their way to Cape Town, the parties having run their course, I killed some time searching the Internet for information about embedded systems.

The result - a nearly complete blank. Keywords like "Embedded", "Embedded Systems" and the like gave Gopher nothing to chew on. "8051", "Z80", and a few other processor names gave one or two hits, but the files had nothing substantial in them.

Embedded technology is so ubiquitous in our society that it is utterly incomprehensible to me that so little information is available about the subject. Perhaps our products have too low of a profile - no one thinks about the computer in your automatic transmission or microwave oven, despite the fact that these little CPUs are so common it's almost impossible to sweep any room visually without coming on at least one thing that embedded technology has made either possible or more effective. Our products are everywhere while our visibility is nonexistent.

One correspondent recently suggested that perhaps a measure of the quality of an embedded system's code is its invisibility; good embedded products just work without ever intruding on our consciousness. Like the Energizer Bunny, but not nearly so annoying.

Where, then, do we go for information? The local libraries are usually worthless. I try to visit the University of Maryland's fantastic library system once or twice a year to search for ideas, but only rarely come up with a meaningful reference to this industry.

Contrast this with any other mature business. Civil engineers have a thousand different handbooks and reference works available, along with schools devoted to the subject. Check out Philosophy and religion - bookstore shelves are groaning with literature. Politics, business, gardening, even "new age" - whatever that means - getting any sort of information about these subjects is so painless that, if anything, many of us wouldn't mind adding a filter to the amount we're swamped with on a day-to-day basis.

Now, some say that hi-tech (what the outsiders usually call the embedded industry) changes so fast that it's pointless or impossible to produce any sort of meaningful records. Hogwash! Look at medicine, which has new developments that come at such a staggering rate that new specialties are created almost daily. Anything you'd like to know about medicine is no more than a phone call away, to MEDLINE or other databases. CD ROMs bring much of the data into our homes. Medicine has worked hard to develop a way to create, maintain, and distribute information widely.

Now, I have heard ad nauseam about the cost of the health care system, and how it is the biggest industry in this country. However, if you added up all of the ingredients of our business I suspect that products with embedded processors constitutes one of the top ten or so industries in America.

Perhaps the industry is too new, though having started engineering at the dawn of the embedded era, my current gray hair would seem to testify the reverse. Read Intel's current annual report, which is a fascinating history (from their perspective) of the embedded industry. The first processor came out 22 years ago, a long time by any but a geologist's standards. A Modest Proposal

For our industry to progress we simply must learn to manage information more effectively. It drives me nuts that we who create the technology used so well by so many other fields are basically inept at using it ourselves.

You disagree? Why must we continue to write code with editors not all that different than those used 20 years ago? Why can't we bring the resources of a Microsoft Word to bear (and I don't mean in some lousy text-only mode. I want italics, fonts and spell checking).

Why do so many of our colleagues refuse to use even simple tools like a Make utility? I see folks every day building batch files instead of make files because "it's too much trouble to set up the make file".

Why haven't hex files gone the way of the dinosaurs now that IEEE-695 and other standards let us mix code and source information?

How many of us use even a revision control system? Who tracks functions in any sort of database to make it easier to remember what one wrote last year? I'm badly guilty of this sin; after writing about 68 articles for this magazine I can't remember what I have talked about, yet so far have resisted building a database with keywords.

This reluctance to use common tools was brought home with a vengeance after my article about real time operating systems came out earlier this year. RTOS vendors warned me that their products were used in only some 20% of all systems with an OS, a fact that was confirmed by the tremendous amount of E-mail I received from those wrote their own RTOS. All of the mail was well reasoned and thoughtful; a lot complained about the size or speed of commercial versions, yet these arguments seem to me to be similar to the complaints against C just a few years ago.

Perhaps these correspondents are right. If they are, though, woe to the future of reusing prepackaged objects!

My proposal is simple: individually, and then later as a group, let's take the first small steps to developing a database of embedded information. Like the environmental saying "Think Globally, Act Locally" we must all work in some manner towards saving the mass of information that unfortunately now has far too transient a life.

The rewards are legion; the perils of not taking this action will be stagnation. Think ahead a year of a decade: if you want to know how to program an 8259 you'll be able to do a search on a database, culling articles, code, and data sheets in seconds. Need a FFT algorithm? Dozens, perhaps hundreds, will all be available on-line. What Do We Preserve?

If we take the medical profession for our model, then it's clearly necessary to save electronic copies of all relevant publications in a format suitable for searching. For example: Jack Crenshaw's articles in this magazine form a block of useful mathematics that we must copy to the database. A number of different publications include fodder for this project, including Dr. Dobb's Journal, Computer Design, EDN, Computer Language, and a wealth of others. Dr. Dobb's is already available on CD ROM.

In many cases, though, we would surely benefit from a multi-author format. I'm sure some of Crenshaw's loyal readers have converted much of his work to practical, useful subroutines. Wouldn't these be a great adjunct to his articles? One of the predictions made for Al Gore's information superhighway is that great works may become collaborations of strangers, each contributing a piece, with no one author really responsible for the whole. Cool idea - let's start now!

Algorithm, hints, tricks - they have filled magazines, newsletters and books for years, yet are today all but inaccessible. We have the technology to preserve this information, and certainly we have the need.

Vendor application notes might be one of the most important resources. I'm constantly amazed by the wealth of good solid technical information some companies work so hard to promulgate. Though these publications are surely never altruistic, one of the wonders of capitalism is that the profit motive can spawn things that help us all. Putting these documents in a less transient, and eventually more widely distributed, form can only form a positive feedback loop beneficial to user and vendor alike.

The trick is to cross reference each article with relevant keywords and an abstract. Most scientific papers include such a header; surely it makes sense to start the same process in our industry. Who defines the standards? Which publication takes the first step? I'm open to suggestions.

Software, perhaps more than anything, must be saved. The planet's investment in code is billions - perhaps hundreds of billions - but by and large most of this is lost, buried in but a single application, never to resurface and see the light of day. The dream of reusability, so crucial to enhancing productivity, will never work unless this problem is addressed.

All of us will have to conform to some coding standard to make this work really well, but clearly this is like hoping for near-term world peace - it ain't gonna happen. I propose, then, a very simple coding guideline that, though far short of a standard, anyone can follow, and that at least forms the outline of a start. Here's my "short list" of suggestions:

Every function starts with a header block, a well written section of comments that explains what the function does in English - not compterese.

The function header contains a list of keywords for use by cross referencing software. These keywords always start with a token (the same token), to make it easy for the cross referencing software to find them. Suggested token: <KEYWORDS>.

A revision history in the function header lists changes, reasons, and the implications of the changes.

The header block contains a complete, accurate description of the parameters to the function (the goesintas and goesoutas).

Variable declarations are all grouped together, and each one is described with a comment.

Don't use a variable for more than one thing.

Don't use global variables.

No function exceeds 100 lines of code. What You Can Do

We embedded developers are the worst communicators. We avoid sharing information; to many live in a shell whose edges are defined by the need to "ship the product!" Perhaps much of this comes from so much military electronics work, where security considerations strike even the most the verbal dumb.

It's time to start talking. Chat up your colleagues. Bug your boss. Convince her to give you a couple of hours a week to, at the very least, collate and store your code and algorithms. Perhaps this is a task for new engineers, who are learning most of what they need by OJT. Exposure to the works of others can only help their education, and their lower pay reduces the cost of the task.

Save stuff. I have maintained an algorithm collection for twenty years, and it has time and again saved my butt. Yeah, it's not electronic. It's a collection of six thick three ring binders of Xeroxed pages taken from this magazine and a dozen others, as well as from books and app notes. It's divided into sections to make data retrieval easier, like Linear Regressions, Sorting, FFTs, Hardware Issues, I/O, and the like. Converting these thousands of pages to electronic form will be a nightmare, but I suppose it is more tedious than difficult. Again, there is no technical impediment to putting the data on-line.

If you have any opportunity to digitize things, by all means do so. Perhaps it is unrealistic to expect to get books, for example, entirely in digital form. The index and table of contents, though, if digitized, will at least leave a pointer trail making it possible to find the data. My Promise

Twentysome years ago we all fervently preached that if you are not part of the solution, you are part of the problem. I guess we weren't thinking about embedded systems, but certainly the philosophy applies to most things in life.

So, if there is an interest in this I'll do my part to help. Next week, at the Embedded Systems Conference, I'll talk to vendors to see if they have tools and/or ideas that may be useful. Since this is really the only time that a significant number of embedded developers gather, it will be a unique opportunity to explore the idea.

I'm willing to serve as a clearing house for information and ideas on the subject. At this time I think it's much more important to answer a few critical questions than to start accumulating data. For instance: how should the information be organized so that it is accessible? Should the Internet be the repository, requiring users to access it via anonymous FTPs? How should we index the data, and who is willing to maintain the index? How are new submissions handled? Is there some sort of QA process, or, like the Internet now, should caveat emptor be the rule?

There's much I don't understand about tools currently available that might help. How does Gopher figure out how to find things? Is World Wide Web a nexus we could tie into to distribute the information globally instead of concentrating it all onto one machine?

Perhaps a compiler company or other organization wishes to pick up this challenge. Certainly, a lot of the code would naturally fit into runtime packages. Just as certainly, though, managing the non-code portions could be too much of a headache for any commercial operation.

If there is a significant amount of interest I'll let you know and try to help piece things together. If not, well, I'll keep brining the idea up from time to time, speaking from this soapbox, to try and convince this industry to take the lead in becoming users of information technology... instead of just its inventors.