How to Become an Embedded Systems Geek

By Jack Ganssle

Disclaimer: I love this field. It's a ton of fun. But jobs can be hard to find. Don't take the following as advice to toss your current career to the four winds and jump into the embedded industry unless you do such from love, for unhappily, long periods of unemployment are far from unknown in this industry.

Update: This issue of The Embedded Muse has an article where readers offer ideas to new graduates on how to get a job in this field.

Update: Here are some resources:

For some reason lately I've been drowning in emails from embedded system wannabees. "Dear Jack: I lately 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? How to I learn about firmware?"

Perhaps my experience was atypical. I helped midwife the embedded business, 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 till achieving some level of mastery.

Times are different now. Then, we were all amateurs. Today expectations are higher, competition for available positions brutal. Lately the staggering economy spawns few new job opportunities; those that surface are more often taken by experienced engineers than newbies.

The Long and Winding Road

Too many of my email correspondents are looking for shortcuts. "How do I convince a potential boss to hire me?" "What book can I read to teach me firmware?" Sorry - there's no easy path, no way to pass Go and collect $200. Though the bookstores have plenty of titles like "Learn to Program in 21 days," don't expect to see an equivalent book for embedded systems.

Perhaps there is one easy way: get an EE degree (see Online Degree Programs in Engineering: http://www.affordablecollegesonline.org/degrees/engineering-programs/). All other approaches will be harder. The degree gives you instant credibility in the marketplace, and today few companies want to hire non-degreed engineers.

Maybe you're a master of C++, a whiz at programming in Windows and the wealth of tools we expect of any desktop computer. That's a fantastic, valuable skill. It does not translate to an "in" into this field. C or C++ are base level skills for any firmware developer, but are merely a subset of the required expertise.

For 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 Linux operating systems. But I believe there are some skills shared by all of the best firmware developers.

First is the ability to work with limited resources. ROM and RAM may be very costly in high volume or low power products. Where on a desktop heaps and stacks are seemingly infinite, 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 sometimes 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.

So 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 web site, 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 experience of developers. Pulse width modulated 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, it's output bouncing for many milliseconds after it's depressed.

Beyond simple I/O, though, the realities of our systems means 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 systems people are expected to be competent at writing ISRs, and must understand how to create reentrant code.

Many firmware applications multitask, generally employing some sort of a real time OS. None of these offer the depth of support common to desktop systems; though some of the commercial OSes give a very complete framework for embedded work, they all look remarkably austere compared to Unix or Windows. Even today many embedded apps 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 be it 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 JTAG, scopes and logic analyzers.

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.

Reading

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, sign up for my free Embedded Muse newsletter. It comes out twice a month and is free. Many managers tell me they quiz prospective candidates about Muse content to see if they are really engaged with the field.

Get familiar with uniquely-embedded issues like debouncing contacts, instrumenting code, watchdog timers, properly using scopes, and approximations.

Read as much as you can. are the best books:

Today the ARM Cortex-M series of processors is the rage. I'd strongly recommend Embedded Systems Fundamentals with ARM Cortex-M based Microcontrollers, Alex Dean - An excellent introduction to the field. It covers both hardware and software issues. Very practical. And The Definitive Guide to the ARM Cortex-M3 by Joseph Yiu.

C Programming for Embedded Systems, Kirk Zurell - A good introduction to working with small systems like the 6805, 6508 and PIC.

Embedded Systems Building Blocks, Jean LaBrosse - a great into to writing peripheral handlers. It also includes his firmware standard, a wonderful model for writing code in a consistent manner.

An Embedded Software Primer, David Simon - This is 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't dos for writing reliable C code. Not a book per se, but a hundred page list of rules. All will make you think.

High Speed Digital Design, Howard Johnson and Martin Graham - The best book available about high-speed issues. The focus is entirely on hardware issues in fast systems. This is for hard-core EE types; expect to do some math.

MicroC/OS-III, The Real Time Kernel - Jean LaBrosse. The best book on real time operating systems. A must-read.

Reviews of these books, plus many others, are at https://www.ganssle.com/bkreviews.htm.

Broke? Download Freescale's introduction to microprocessors. It's a fabulous 300+ page book that gives basic insight into many aspects of working with microprocessors. It addresses the pretty-much-obsolete 6805, but all of the principles discussed are relevant.

Read code, too, to see how experienced developers actually make things work. I especially recommend reading the source to ecos, an open-source RTOS. Or look at FreeRTOS. Even better, as of 2020 uC/OS is open source, and is really well-done code.

Another resource is the free on-line class that the University of Texas has, which looks pretty great. More here.

Build Stuff

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 initially appears as insurmountable problems, that the boss demands we overcome.

Miro Samek has a free set of videos on YouTube which explain the basics (and more) of writing in C for the ARM Cortex-M series of parts. This is one of the more important microprocessor families around today. If you buy the suggested $12.95 board, you can use IAR's free IDE (Miro shows exactly how to obtain and configure it) and work in parallel with the lessons. Unlike other C classes, in this series you'll get exposed to both the C code and what the processor is really doing behind the scenes. That's critical info for any embedded developer. Highly recommended.

Digilent (http://www.digilentinc.com/) has a lot of training resources. Their Analog Discovery and Analog Parts Kit are a great way to learn about analog design. In the embedded world we're always interfacing to analog circuits.

http://www.avrfreaks.net offers several hundred projects, all free, all on-line, ranging from the deadly dull innards of filesystems to robotics, MP3 players, telescope controllers and much more. This very deep site devoted entirely to the AVR line of processors also lists tools, free and otherwise. Read the "Newbie's Guide to AVR Development" and pass the wisdom on to an interested kid.

Want ideas for a project to build? Check out http://instruct1.cit.cornell.edu/courses/ee476/ideas/EE476.project.ideas.html.

For parts and supplies it's hard to beat Digikey (http://www.digikey.com), which has everything electronic, from resistors to complete development platforms.

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 1000 line project will teach a lot, but by the time the code reaches 5-10,000 lines of code it starts to resemble a simple but real-world app.

Conclusion

Without an appropriate degree, expect to work for a time as an intern or apprentice. Your salary will drop till you can acquire and demonstrate your competence. I suspect few people can avoid this painful reality.

Don't be afraid to ask lots of questions. . . . and be determined to move ahead.

Don't be afraid to advertise your career dreams; let your current boss know you want to get into the embedded side of the business (if there is one). These days few companies are hiring, so it's easier to make a lateral move from within the organization.

This sounds like a huge amount of work, and it is. If it's too much, maybe you're not cut out for the embedded industry. I suspect that most great 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.

Oh - and sign up for The Embedded Muse newsletter. Many engineering managers tell me they ask all job applicants if they read it. Those that don't face an uphill battle. Sign up here.