When my first book was just a proposal on the desk of an editor at O’Reilly & Associates, there were just one or two books about embedded programming in C. Half a decade later there are literally dozens of books on that and related subjects, with new titles introduced monthly from a number of publishers. Yet almost all of the “embedded books” to date have focused on software; very little attention has been paid to hardware design directly.

O’Reilly is again leading the way by publishing Designing Embedded Hardware, by John Catsoulis. To be honest, I myself didn’t at first see why the world needed this book—until, that is, I reviewed an early draft last year. In hindsight, I see that this book is much overdue.

I am an electrical engineer by education, yet I have spent my career working entirely as a programmer. Despite years spent earning a BSEE and a later MSEE, I’ve never designed anything more than a toy circuit. Though I know how to read a schematic, am handy with an oscilloscope, and know the smell of liquid solder (and burnt fingertips!) firsthand, if I were assigned the task of designing hardware I wouldn’t know where to begin.

That’s where Designing Embedded Hardware comes in. The author assumes “nothing about your knowledge beyond a rudimentary understanding of digital and analog electronics.” That’s just what I needed someone to do to teach me to develop the hardware too. And I have a strong feeling I’m not the only programmer who could use such hand holding.

This book begins by outlining the basic principles of electronics and computer architecture, in a much more efficient, practical, and accessible way than the typical textbooks. By page 77, in fact, you’re ready to start applying those principles by designing circuits. The fun starts officially in Chapter 4, which gets into construction options (breadboards, wirewrap, and printed circuit boards), routing and signal quality concerns, and hardware debugging. There’s even a primer on soldering for the uninitiated.

The remainder of the book consists of two sections. The first of these contains chapters dedicated to designs based on each of various popular microcontroller families—specifically Microchip’s PIC, Atmel’s AVR, and Motorola’s 68k processors and 56000-series DSPs.

The third part of the book deals with peripherals and interfacing. The list of such design topics is long and includes implementing SPI and I2C busses, communicating serially (including RS-232C, RS-422, IrDA, and even USB), networking with RS-485, CAN, and Ethernet, and analog interfacing (e.g., A/D, D/A, sensors of various types, PWM, and motor control). And remember this is a hardware design book, so each of these discussions is complete with a circuit design for a common IC implementation.

For too long hardware design has been a black art. Or maybe it has just seemed so because of the lack of good books on the subject. I hope John Catsoulis’ new book will be as successful in the market as it was in showing me how to design hardware. I can’t wait to put my new skills into practice.

The current state of the embedded systems industry reminds me of a song and a movie, one with a positive connotation the other negative.

Despite the current pullback, all the long term trends point toward steep growth for the embedded industry (and technology in general). The simple fact is that more than 99% of the processors manufactured each year are deployed in embedded and real-time applications. And the numbers of processors coming off production lines is projected to double easily by 2010.

Looking ahead a few years, all I can see is a world with many more embedded devices, automated control systems, and other nifty gadgets of the sort we create. How many products won’t have at least one CPU inside by 2010? So many processors, so little time! And far too few hardware designers and embedded programmers, at least here in the U.S., to bring all of them to market. Ahh, “The Future’s So Bright”… Particularly for those with our sort of specialized skills, as well as for companies offering tools and components that make the work more efficient.

So why is the current downturn hitting the embedded industry so hard? For example, why are many more embedded developers out of work now than at any previous time? And what’s happened to the previously rapidly expanding markets for ICs, development tools, and real-time operating systems?

I believe we’ve been hit by a double whammy: the combination of a normal economic downturn and a retrenchment from overinvestment in technology. Hence, we’ve got buried twice as deeply as we should have.

At the end of the last decade, embedded systems growth got a bit ahead of itself, primarily in two areas: telecom and Internet. On the telecom side, too many competitors were each spending too much money in a race for wireless and Internet customers. Each believed they would see a huge ROI if only they could build their own infrastructure bigger and faster, so they kept spending; few foresaw that the total capacity being put into place would result in a huge oversupply, which it now has.

Simultaneously, the growth of Internet users, uses, and sites suggested huge opportunities for new ventures. Some of these focused on developing new “Internet appliances”; many more on connecting previously-unconnected systems via TCP/IP. A fair number of these ventures were, unfortunately, spectacular failures, and the term Internet appliance has even come to somewhat represent that collective failure (though “connectivity” clearly lives on).

Both the economy and past overinvestment will eventually correct themselves. Meanwhile, though, it’s February. And somewhat like Bill Murray’s character in the 1993 film “Groundhog Day,” I’m wondering if this year’s predictions of renewed economic growth in 2003 are any more likely to come true than those made last Groundhog Day.

It may still be some time before we can dig ourselves out from the current economic weakness, but it’s hard to argue against betting on the long-term future of embedded systems. Whether it’s in the automotive, consumer electronics, medical, military, aerospace, or telecom sector, the growth in processor inclusion is bound to return; hopefully with a vengeance. Meanwhile, you’ll excuse me while I look for my shades.

Embedded computers appeared a full decade before personal computers. Yet a generation later many define embedded as “anything but” its popular successor. What’s going to happen to the embedded category in the future? Can an increasingly disparate mix of systems continue to be identified as similar in their dissimilarity?
Personal computers—whether “IBM-compatible,” variety of apple, or UNIX workstation—are easy enough to describe. The English word “computer” is enough to put that very image in the mind of at least a billion people; a quarter as many own one.

Embedded systems are completely different. Few other than engineers have heard the term; most people don’t even notice if their microwave or cell phone has a computer at its heart. Even the designers of such systems can’t always agree on what exactly the term means.

Personal computers are, upon consideration, just a family of similar products (a particular vertical market)—no more different from one another than cell phones. Yet the world’s billion plus cell phones are frequently lumped into the same broad catch-all category as anti-lock brakes and cruise missiles: embedded systems. Why should that be?

Why should PCs be different? Don’t PC designers have as much in common with cell phone designers as the latter do with anti-lock brake designers? Where do we draw the line: is a PDA a general-purpose computer or an embedded system? What about a cell phone (or oscilloscope) with a Java Virtual Machine and application manager?

By 1999, the percentage of new 32-bit processors destined for PC motherboards had dropped to a rounded 0%. That alone suggests the segregation is no longer appropriate. But if we accept that, doesn’t it mean that embedded, as a category, doesn’t actually exist? That there are instead a large number of vertical market segments: automotive electronics, office equipment, telecom/datacom, consumer electronics, avionics, industrial automation, personal computers, etc; each representing a different type of computer.

Such vertical markets clearly already exist. There are trade associations, journals, conferences, and other signs of “community” in each. So what holds the embedded development community together? Why do we choose to identify ourselves as designers of embedded systems, rather than designers of avionics or cell phones? And will we continue to do so into the future?

I think it’s the skills that matter most in this. We identify ourselves as embedded designers up to the point that we feel our skills are transferable between these various markets. The company Cisco doesn’t think of itself as an “embedded system design company”—though many of the engineers who work there may consider that they do just that. The skills we learn from other embedded programmers through community resources online, in print, and in person help us keep a broad perspective. Though we only write software for microwave ovens today, we might write software for avionics systems tomorrow; the same basic skills apply.

So there is an important similarity that binds us together after all. I don’t see that changing anytime soon. If anything, I expect there will be many more people joining our community in the coming decades. And though the customers who buy our products may not consider them embedded computers, those of us who design them always will.