This year marks the 20th anniversary of Embedded Systems Design (ESD) magazine. That's a noteworthy achievement, but it's creating a bit of a mid-life crisis for some of us. “What did embedded systems look like 20 years ago?” “What will they look like 20 years from now?” “Does this power supply make me look fat?”
The answer, it turns out, is that it doesn't matter. There's no longer any such thing as an embedded system.
Richard Nass, ESD's editor in chief, likes to describe an embedded system as “a computer whose end function is not to be a computer.” According to him, microwave ovens and televisions are embedded systems because they contain computers but aren't intended to be computers. Conversely, the desktop computer I'm using to compose this article is not an embedded system as Rich defines one, because it contains a computer that is intended to be a computer. Or something like that. Rich's definition is pretty conventional.
With all due respect, that definition is wrong. The reason it's wrong is because there's no longer any such thing as an embedded system. Honestly, there never has been such a thing. Let's look at some examples that prove my point. How would you define my desktop computer if, in addition to running Emacs, it was also controlling my lawn sprinkler system? Or my home heating and air conditioning system? And this will happen, just as soon as I can get my wife and kids out of the house for a couple of days.
I recently worked with a client whose product is a control and monitoring system built from rack-mounted x86 server motherboards. The operating system is based on a real-time Linux kernel, and big chunks of the application logic will be written in Java. That application is the control loop, not just a babysitter for it. The system will probably even sport an e-mail transfer agent and web server, so it can “phone home” for help and status checks.
Several ongoing professional projects of mine involve mobile, non-x86 platforms running Linux. At least one is running an in-memory database management system that speaks SQL, and at least one more will likely choose to go that route as well. Both products will feature web servers and e-mail capabilities, and have 802.11 networking built-in so they can push data to a service center whenever there's an open access point in range.
I just finished a firmware updater for a product using flash memory. That product also had a web server, and it took lots of Java script to make sure the user saw what we wanted them to see in their browser window before, during, and after the firmware updating process.
The control system example is PC hardware, doing a lot of non-PC-like things. The other examples aren't PCs, but they run a lot of software commonly associated with PCs. So it seems that there's no point in trying to assign an “embedded” vs. “non-embedded” label to a product based on what kind of hardware or software it uses.My Treo 700p cell phone meets Rich's definition of an embedded computer, so long as I choose to not use it as a general-purpose computing device. But what about when I start adding programs that connect to a company's back-end business applications, so I can check product inventory and delivery schedules? Or an SSH client, so I can connect to my Linux workstation to check on a long-running process? The device itself is unchanged, I'm just using it differently. Hence, there doesn't seem to be a point in defining embedded vs. non-embedded based on what the device does or how I use it, because those kinds of things can change easily.
So let's discard Rich's definition of embedded, despite its considerable entrenchment in our industry, because it just doesn't work. But what do we replace it with?
A new definition
It's human nature to want to try do create an “us” and a “them.” Readers of this column generally know who “they” are. We do the real programming, and “they” don't. We know what a stack pointer is, because we program in assembly language. They don't, because they use wimpy languages like Java, Ruby, and PHP. We program in ones and zeros, sometimes using all zeros. They never program at all.
To date, this us vs. them mentality has been a great way for us to confine our range of available solutions to just those labeled “embedded.” We have our toys and they have theirs, so that keeps them out of our sandbox.
That time is now over. Let me give you another example why. I recently met a young developer with a strong .NET background, who had been reassigned to his first “embedded” project. The task was to add an LCD panel to a piece of industrial control equipment, which communicated with the panel over a CAN interface. The application was to be written in C, the hardware was completely custom.
The Linux kernel they were using on their non-x86 target hardware was having problems, and they weren't sure why. I was brought in to help tidy things up. This developer had continued coding his application, using Eclipse on his Linux PC and automated unit testing techniques learned from his .NET days to ferret out bugs while I dealt with the target environment.
Fast forward a few days. The target hardware and Linux kernel were now solid. His first attempt on the target board demonstrated a bug that he had seen in his unit testing a few days prior, and had fixed. Turns out that the target wasn't running the latest code, a problem that was easily remedied with a quick update from his Subversion repository. At the end of the day, the whole migration of his code to the target was a non-event. I use the term “migration” somewhat loosely, as he had no plans to abandon his x86 environment.
Now, this example is not my endorsement of .NET, Linux, agile programming, Subversion, CAN, or anything else I might have mentioned. It's merely to point out that the skills that they are using are skills that we need. But we aren't going to get them if we continue to put up walls between us and them.
You might be thinking that you don't need to worry about any of this, because you're doing “deeply embedded” work with 8-bit microprocessors. There's nothing for “them” to teach you, right? Wrong. The overwhelming majority of the devices Rich defines as being embedded systems are powered by 8-bit microprocessors, and I see virtually unlimited growth in these target applications over the next two decades. I don't have a crystal ball, or even a marketing survey, but I don't see us stepping up to 32-bit processors in our tooth brushes. And just like I didn't predict microprocessors in tooth brushes, I have no idea where else we'll find places for them. But I'm confident we will.Based on my own observations, however, “we” are the ones that have the most code laying around in ZIP files and the like. While it's true that you probably won't be using .NET or Java on your PIC or 8051 any time soon, you could do more things like automated unit testing and defect tracking.
For 20 years, Embedded Systems Design magazine (formerly Embedded Systems Programming ) and its audience have led the way in introducing computers to every area of our lives. Today, computers brew our coffee and restart our hearts. They fly our airplanes, scan our e-mail for viruses, and send us text messages to tell us our tires need air or to remind us to get flowers on the way home.
At the same time that technology is enabling computers to do more of the tasks we wish to assign to them, we're also getting better at identifying more tasks that computers can do. So there's no risk of our industry running out of things to do any time soon. It's amazing that we've managed to sustain 20 years of unbelievable progress in embedded systems while simultaneously rejecting so much progress in non-embedded domains that could benefit us. I don't see how we can repeat this feat. Nor do I want to try.
Readers of this column generally have unique skills that let us bend computers to our will. Knowing about stack pointers, for example, is incredibly important. In the coming years, we must augment those with new skills and tools that let us approach and succeed at an ever-increasing number of more diverse projects than ever before.
That means we've got to throw away our current definition of embedded. Not redefine it, but discard it altogether. Because as long as we have a definition for embedded, we can choose to ignore that which is “not embedded.” And we really don't have that choice.
Bill Gatliff makes free and open-source technology work for embedded applications. Specializing in Linux kernel porting and real-time applications for more than a decade, Bill also provides some of the most sought-after, in-depth, up-to-date consulting and training on topics related to real-world embedded systems. His background includes automotive, aerospace, and medical applications. Bill is a contributing editor to Embedded Systems Design magazine, and a member of the advisory panel to the Embedded Systems Conference.