A degree doesn't make you an embedded systems engineer. Here are some tips to get you started; if you're already there, they'll help you improve.
I'm writing this from my sailboat, at anchor in Bermuda. There's no 'Net access on board, so once a week I head for an Internet cafe ashore and dig through the e-mail. I've lately been drowning in e-mails from embedded system wannabees. “Dear Jack: I learned Visual C++ and now want to start a career in firmware. But no one wants to hire me as I have no experience. What do I do?”
Perhaps my experience was atypical. I helped midwife embedded, learning while building products using the very first microprocessors. Like mastering the mysteries of the birds and the bees, I ran experiments, checked the results, talked to friends, and iterated toward some level of mastery.
Back then, we were all amateurs. Today, expectations are higher, competition for available positions is brutal. The limping economy spawns few job opportunities. Those that surface are more often taken by experienced engineers than newbies.
For people going from college to real life, I recommend hiding out for a year or two, if you can afford it. Consider getting an MS degree. If your BS is in computer science, take electrical engineering classes. Since the job market is so depressed, it makes sense to optimize your skills for when good times return.
And they will return. It seems we hit a bad economic patch in the beginning of each decade. Each one feels overwhelming, but they all pass. In the early '70s, engineering collapsed with the loss of the Apollo program. Inflation and other woes caused a big contraction around 1980. The recession of the early '90s killed the elder Bush's reelection bid. Our current problems, too, will pass, fading into distant memory.
The long and winding road
Too many of my e-mail correspondents are looking for shortcuts. “How do I get a boss to hire me?” they ask. “What book can I read to learn firmware?”
Sorry, there's no easy path. Though the bookstores have plenty of titles like Learn to Program in 21 Days, don't expect to see an equivalent for embedded.
I wonder if this search for shortcuts is a quintessentially American characteristic. We're so anxious to do things right away. As a parent, I'm constantly astonished to find how kids need to go through so many experiences themselves. They can't learn from my hard-won insights. There's something intrinsic to humans about learning by doing.
Maybe you're a master of C++, a whiz at programming in Windows using MFC and the wealth of tools we expect of any desktop computer. That's a fantastic, valuable skill. It does not, however, translate to an “in” into the embedded industry. C or C++ are base-level skills for any firmware developer, but they're merely a subset of the required expertise.
There's a huge gulf between the resource-rich environment of a desktop machine and a typical embedded system. It's tough to generalize about firmware, because some projects run on 4-bit micros in 100 words of code, while others boot complete Windows or Unix operating systems.
But I believe there are some skills shared by all of the best firmware developers. The first is the ability to work with limited resources. ROM and RAM may be costly in high-volume or low-power products. On a desktop, heaps and stacks seem infinite, but we firmware folks sometimes trim each to a razor's edge (too often with catastrophic results). The Windows developer knows how to speed transcendental math using lookup tables, but his embedded counterpart looks askance at the often staggering memory requirements. We use C subsets on minimal processors, where sometimes the pseudo-C is just a cut above assembly. Processors with poor stack architectures invariably spawn compilers that play complex games with automatic variables, games that can and will bite back when used by the unwary developer.
It's not uncommon for time to be in short supply as well. There are limits to how fast a small processor can move data around. Moore's Law does not bring the embedded developer a faster CPU every few months. When the system is performance-bound, embedded engineers re-design code, tune routines, and even, at times, change the hardware design.
The accomplished firmware developer is a master of cramming more into less-more features into less memory, more performance into fewer CPU cycles. Assembly language always lurks, if only to understand what the compiler generates.
Embedded systems interact in complex and strange ways with the system's peripherals. We're not downloading drivers from some vendor's website, or relying on a vast infrastructure of OS support. Design a simple data acquisition system and odds are you'll have to initiate A/D conversions, suck in data, and scale and normalize it. Working with a serial channel, expect to write your own circular queue handlers.
We firmware folks are responsible for even the most basic of all functions. On most processors, we must set up chip select pseudo-peripherals to determine the location and extent of all memory devices, as well as the number of wait states required.
Peculiar devices challenge even the most experienced of developers. PWM outputs aren't uncommon yet defy many people's understanding. Log amp compression circuits scale inputs in confusing ways. Even the straightforward switch behaves very strangely, its output bouncing for many milliseconds after it's depressed.
Beyond simple I/O, we must be masters of interrupts and DMA transfers. Data arrives from a plethora of asynchronous sources and must get routed out as needed. Embedded designers are expected to be competent at writing interrupt service routines, and must understand how to create reentrant code.
Many firmware applications multitask, generally employing some sort of real-time operating system (RTOS). None of these offer the depth of support common to desktop systems. Though some commercial RTOSes give a complete framework for embedded work, they all look austere compared to Unix or Windows. Even today, many embedded applications don't and can't use an RTOS, but the well-rounded developer must be versed at multitasking.
Debugging is especially difficult in the embedded world. If you've been spoiled by Microsoft's debugger, expect culture shock when trying to peer into the workings of your firmware. In the best of cases, there's darn little visibility into the workings of our code. Sometimes we're required to amend the hardware and software design just to make some sort of debugging possible-even something so humble as wiggling pins and monitoring their states on an oscilloscope.
If you can't debug, you can't make your stuff work, so plan to understand in-circuit emulators, background debuggers, scopes, and logic analyzers.
Embedded applications are-or should be-much more reliable than their desktop counterparts. A Word or Excel crash doesn't compare to an avionics problem that kills hundreds. Less dramatic failures are just as serious. Having to stop every 20 miles to reboot your car controller is simply unacceptable. Few PC applications run for more than a few hours at a time, so memory leaks can often go undetected by the average user who turns the machine off each night. By contrast, an embedded product might have to run for years without cycling power.
To build reliable code, we must understand and practice more extensive design than is common in other software projects. Failure mode analysis is required for some products. Extensive exception handling is a must. Code coverage tests are mandated for high-reliability projects.
Become an expert C/C++ programmer. Gain competency at assembly language. Master all of the above. That gives you the basic skills needed for firmware development.
An embedded occupation can be lots of fun, personally satisfying, a creative outlet, and reasonably financially rewarding. A lot of folks see these desirable traits after embarking on other vocations and search for ways to make a mid-life change. For most of these people, various family responsibilities make going back to college for an EE or CE degree impossible. In this case, you have to design your own curriculum and advance your own career strategy.
First, read as much as you can. Here are a few suggestions:
- Bebop to the Boolean Boogie, by Clive Maxfield. A fun and interesting digital design book aimed at folks wanting to understand the hardware.
- C Programming for Embedded Systems, by Kirk Zurell. A good introduction to working with small systems like the 6805, 6508, and PIC.
- Embedded Systems Building Blocks, by Jean Labrosse. A great intro to writing peripheral handlers. It also includes his firmware standard, a wonderful model for writing code in a consistent manner.
- Embedded Systems Design, by Arnold Berger. A nice intro to the embedded world, with a focus on tools. Also has good hints on selecting processors.
- An Embedded Software Primer, by David Simon. The best introductory book available. Highly recommended.
- Guidelines for the Use of the C Language in Vehicle Based Software, by MISRA. This is a list of dos and don'ts for writing reliable C code. Not a book per se, but a 100-page list of rules. All will make you think.
- High Speed Digital Design, by Howard Johnson and Martin Graham. The best book available about high-speed issues. The focus is entirely on hardware issues in fast systems.
- MicroC/OS-II: The Real Time Kernel, by Jean Labrosse. The best book on RTOSes. A must-read.
- Programming Embedded Systems in C and C++ , by Michael Barr. An extremely useful introduction to the subject, with projects for self-study.
- Serial Port Complete, by Jan Axelson. A complete reference to serial communications. Handling serial data is a basic skill for every developer.
Read www.embedded.com and www.chipcenter.com regularly. Scan every issue of Dr Dobb's Journal, Embedded Systems Programming, and EE Times. Clip and study Embedded Systems Programming's “Beginner's Corner,” which is mirrored on www.embedded.com/columns/bc.
Read code, too, to see how experienced developers actually make things work. There's plenty scattered around the web, on sites like www.8051.com, www.chipcenter.com, www.microchip.com, and the like. I especially recommend reading the source to eCos (www.redhat.com), an open-source RTOS. Even better, read the source to Labrosse's C/OS, available in the previously mentioned book and on www.ucos-ii.com. Both of these operating systems are the very model of how we must write code: beautiful, well documented, clear, concise, and extensible.
Book knowledge is crucial but complement it with practical experience. Do projects. Build things. Make them work. Expect problems, but find solutions. Don't abandon a project because it's too hard or you're confused. Most real development efforts are plagued by what appear to be insurmountable problems that the boss demands we overcome.
Spend some money on hardware for these projects. Consider, for example, Parallax's Stamps In Class curriculum (www.stampsinclass.com). It's an underpowered machine that offers enough performance for early learning.
Move from that to a C-based system, like Rabbit's evaluation boards (www.rabbitsemiconductor.com) or an x86 board (ssv-embedded.de/ssv/pc104/p169.htm). Another fun board is the 68HC11EVM (www.motorola.com).
Start with simple projects, like LED blinkers, but keep challenging yourself. Add a timer ISR to manage the blink rate. Read real-world data from an A/D converter, process it, and display the results on an LCD. Send data to a PC over a serial link. Build a command handler so the PC can issue various instructions back to your embedded system.
You'll be on the way to mastery when the programs become large, not from lousy implementations, but due to the demanding nature of the project. I figure that a 1,000-line project will teach a lot, but by the time the code reaches 5,000 to 10,000 lines, it starts to resemble a simple but real-world application.
For love of the game
Without an appropriate degree, expect to work for a time as an intern or apprentice. Your salary will drop until you can acquire and demonstrate your competence. I suspect few people can avoid this painful reality.
This is a huge amount of work. If it's too much, maybe you're not cut out for the embedded industry. I suspect that most developers succeed because they love doing the work. Indeed, various salary surveys show that, for engineers, money is one of the least important motivating factors. Doing cool projects inevitably ranks first.
Is it fun all of the time? Of course not. We pay for the thrills by wading through mind-numbing technical articles and putting up with unenlightened bosses. But if you love technical challenges, fighting really tough problems that span the range from hardware to software to even the basic science of some devices, embedded is the field for you. Be tough, be determined, think long-term, and have fun.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at .