embedded software boot camp

Designer's Bookshelf

April 4th, 2003 by Michael Barr

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.

Moving Targets

March 3rd, 2003 by Michael Barr

There are currently so many interesting operating systems and alternatives that it’s hard to choose—as we must for each project—just one. Within the priority-based preemptive category, you can choose based on worst-case latency, source code availability, upfront and/or recurring cost, memory usage, API/features, and numerous other criteria. Indeed, the realm of possible price/feature combinations has fragmented the market into many tiny niches.

Though there are a handful of well-known names that have the bulk of the market tied up, a sizeable number of smaller RTOS providers do quite a nice business on just a tiny fraction of total market share. And as the demand for embedded operating systems continues to accelerate, these smaller vendors need not even hold their market share numbers to continue to increase profits. That’s good—because they will continue to lose market share.

There are a lot of forces that will shape the RTOS marketplace going forward—as it goes even more toward the big guys. Not the least of these factors is that more of us will go off-the-shelf. Among subscribers to Embedded Systems Programming magazine, for example, the percentage using no OS or a proprietary alternative has fallen from 38% to about 18% in just the past five years. Extrapolating, perhaps we’ll all be using off-the-shelf OS code by 2007.

Competition from “desktop-lite” operating systems has also picked up. There are a large number of embedded designs that look (or can look) an awful lot like a PC inside, benefit from the low component costs in that market, and no more than dabble in the realm of real-time. What used to be a small ROM-DOS market has morphed into today’s WinCE/XP and Linux market—almost entirely in the last three years. In 2002, some 17% of you fell into that category; I suspect it’s not a coincidence that x86 architectures continued to dominate the list of 32-bit processor choices.

And then there’s consolidation. Though the pace of consolidation has slowed with the business cycle, the effects continue to be felt. Mostly it was the vendors of 32-bit solutions that picked up 8- and 16-bit competitors and debugging tools when times were good—so they could offer one-stop shopping. An up-and-coming Linux player even spent some of its paper wealth to acquire a commercial RTOS vendor for that same purpose. To compete, a large commercial vendor picked up an open source, though non-Linux, OS. When the buying resumes, as it surely will, where will it ultimately end?

Several of the technologies positioned to profit from these trends are not what we traditionally think of as “embedded.” Microsoft, which—love ‘em or hate ‘em—correctly understands they must make it in the embedded space to stay relevant in the coming decade, is trying hard to find the right combination of OS features and vertical markets. In many of these markets, they’re competing directly against the open source alternatives—and apparently losing in some. According to a recent article in EE Times, Linux is also beating out traditional RTOSes in key markets like consumer electronics.

Of all the traditional vendors, Wind River is probably in the best position to compete with these market forces and survive. We are fortunate in the embedded space to have lots of choice when it comes to operating systems. But the future may hold far less technological alternatives. It’s not clear to me that QNX, VxWorks, Nucleus, or any other RTOS is really distinguishable from another in the boardroom—or that the smaller players have enough to gain by staying in the business longer term. What do you think?

The Long Winter

February 15th, 2003 by Michael Barr

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.

Electronic Voting

January 5th, 2003 by Michael Barr

Many people take the position that electronic voting is less trustworthy than paper-based balloting. Without dismissing their concerns, I think we should also consider some of the positives that electronic voting may bring. Having moved this fall, I had the unlikely experience of using a shiny new touch screen electronic voting machine during the primary, then going back to a paper ballot during the general election. Traveling backward in technology like this gave me lots to think about.

Some of the really nice things about the touch-screen system are the ease with which a voter can change his mind or correct a mistake, and the virtual certainty that you’ve cast all the votes you are allowed and that they’ve been properly read. Misvotes, undervotes, and overvotes are all possible with optical scanners and other paper-based systems, since the ballot readers don’t give the voter any feedback. However, electronic touchscreen voting eliminates these issues.

Beyond the RTOS

December 12th, 2002 by Michael Barr

Selecting a plural form for RTOS is hard; there is no one right way. Some possibilities, listed in order of increasing popularity (on the Web), include RTOS’s, RTOSes, and RTOSs. The first implies a possessive aspect that’s clearly not appropriate, so that variant is best avoided. Between the other two, the vast majority of trade journals have adopted RTOSes as their preferred style. Though, apparently, not everyone is yet convinced.

In addition to trying to standardize the language readers use to communicate with one another, an important role of trade journals is helping spread useful new techniques and best practices quickly. For example, numerous articles and columns in past issues of Embedded Systems Programming have helped popularize the use of RTOSes. Approximately half of that magazine’s subscribers now use a commercial RTOS to get the job done.

Unfortunately, however, most of the differentiation between the hundred or so RTOS vendors is on the price and support side, leaving embedded programmers to develop their own solutions when a preemptive priority-based scheduler doesn’t fit the problem at hand. In fact, as RTOS vendors continue to argue against “rolling your own” and worry about lower-cost or no-cost competitors, I would argue that most are overlooking the technically obvious.

Static-priority preemptive schedulers, with priorities assigned rate or deadline monotonically, work very well in certain real time systems with high degrees of both parallelism and periodicity. Telecom and datacom products, with their many communication channels, are often of this type.

But the tradeoffs, including increased interrupt latency and potential priority inversions, are significant. Though it can be made to fit some, the static-priority preemptive solution just doesn’t fit the needs of a large population of systems quite right. Some tasks are periodic, but many others are not. Some systems have hard deadlines, but many others do not (or can safely miss a few now and then). In such cases other types of multitasking (or even the lack thereof) may be preferable to the much-touted RTOS.

Alternative ways of structuring embedded software run the gamut from simple main()+ISR implementations to the use of dynamic priorities. For example, a simple executive is a low overhead technique that works quite well for hard real-time systems with harmonic deadline periods and a small number of things to get done. And state machines can be executed in a series of run-to-completion steps via a framework like that outlined in Miro Samek’s excellent book Practical Statecharts in C and C++ (CMP Books). Taking another approach, Java and Ada support threads natively, making the choice of a particular RTOS largely irrelevant.

My point? The hundred plus commercial RTOSes available today have too much in common technically. Not every embedded designer benefits from adding a static-priority preemptive scheduler; many software designs are, in fact, harder with preemption. RTOS vendors might do better to view themselves as providers of software frameworks for developing embedded software, and differentiate themselves by offering more than one technique. Just as there are currently various ways of pluralizing RTOS, there are also various ways of doing without one.