I am being approached with a job for writing embedded C on micro controllers. At first I would have thought that embedding programming is too low on the software stack for me, but maybe I am thinking about it wrong.

Normally I would have shrugged off an opportunity to write embedded code, as I don't consider myself an electrical engineer. Is this a bad assumption? Am I able to write interesting and useful software for embedded systems, or will I kick myself for dropping too low on the software stack?

I went to school for computer science and really enjoyed writing a compiler, thinking about concurrent algorithms, designing data structures, and developing frameworks. However, I am currently employed as a web developer, which doesn't scream the interesting things I just described. (I currently deal with issues like: "this check box needs to be 4 pixels to the left" and "this date is formatted wrong".)

I appreciate everyone's input. I know I have to make the decision for myself, I just would like some clarification on what it means to be a embedded programmer, and if it fits what I find to be interesting.

8 Answers 8


If you want to be good at working on embedded systems, then yes, you need to think like a EE some of the time. That is generally when you are writing code to interface with the various peripherals (serial busses like UART, SPI, I2C or USB), 8 and 16-bit timers, clock generators, and ADCs and DACs. "Datasheets" for microcontrollers often run into the hundreds of pages as they describe every bit of every register. It helps to be able to read a schematic so you can probe a board with an oscilloscope or logic analyzer.

At other times, it is just writing software. But under tight constraints: often you won't have a formal OS or other framework, and you might have only a few KB of RAM, and maybe 64 KB of program memory. (These limits are assuming you are programming on smaller 8 or 16-bit micros; if you are working with embedded Linux on a 32-bit processor, you won't have the same memory constraints but you will still have to deal with any custom peripheral hardware that your Linux distro doesn't provide drivers for.)

I have a background in both EE and CS so I enjoy both sides of the coin. I also do some web programming (mostly PHP), and desktop apps (C# and Delphi), but I've always enjoyed working on embedded projects the most.

  • Thanks for your answer. The constraints don't really bother me. I just think of myself as a software guy, and not an electrical engineer. Would you say "low level programming" is the same as "high level electrical engineering"?
    – Jeremy
    Commented Nov 30, 2010 at 14:40
  • +1 for the 32-bit and Linux observations - I used to work in telecomms and the switch hardware was like coding for a stripped down version of an Amiga (Motorla 68k processor). Had some very happy times - miss it sometimes.
    – Gary
    Commented Nov 30, 2010 at 16:51
  • 3
    @Jeremy, yes, when you are trying to figure out the settings for a complicated peripheral, or looking at a serial bit stream on a scope, sometimes it seems you are doing low-level programming and sometimes you are having to think like a high-level EE. You might spend a lot of time looking at register contents inside debugger windows of an IDE. At that level, you are looking directly at the hardware.
    – tcrosley
    Commented Nov 30, 2010 at 21:24

@tcrosley's answer is excellent. You do not need to be an electrical engineer, but knowing the basics helps.

I don't think you need to fear being "too low on the software stack". I've had to solve many very interesting problems as an embedded engineer. You mention a list of tasks you enjoyed:

  • Concurrent algorithms - Dealing with asynchronous hardware level interrupts has as many interesting challenges as using an OS thread model.

  • Designing data structures - Check. Design for compactness and efficient access.

  • Developing frameworks - Check. On bare bones systems, you can end up designing a mini-OS.

  • Writing a compiler - maybe not, but you can end up doing low-level code optimization similar to the assembly generation step of a compiler.

I'd pick working on embedded systems over coding UI's any day. You'll never forget the first time you watch a machine start moving the way you programmed it to. It's way more satisfying than pushing pixels.

  • Thanks for the 1-to-1 mappings AShelly. Knowing really nothing about the embedded work environment, it's good to know that.
    – Jeremy
    Commented Nov 30, 2010 at 21:53

As an embedded programmer, my job is to make custom hardware work. Typically, I have developed a bunch of software on a dev board, or a previous version of hardware. When the new board comes in, my job is to put my software on the board and demonstrate that everything works.

Because there is almost always a problem of some kind, debugging skills are essential. If the external peripheral doesn't work, is it a bad chip, bad connection to the chip, buggy code or incorrect use of the on-chip peripheral? The only way to tell is with extensive debugging. This means being comfortable with oscilloscopes, network analyzers, logic analyzers and target debuggers. The debugging process becomes almost scientific. I develop a hypothesis, design an experiment to provide evidence for or against my hypothesis, and test.

When evaluating interns or new embedded engineers, this skill is the most critical. All software has problems, but once you start interfacing with the physical worlds, the variety of those problems increases exponentially. The essence of my job is to solve the long series of problems between concept and reality.

  • True, debugging is an essential skill for an individual embedded programmer - particularly the kind of debugging that involves looking at the display of a storage scope attached to the tracks on a PCB to diagnose a problem with the embedded software. :-) - However, a greater virtue in a team of embedded software engineers is the ability to catch errors automatically through advanced testing and quality control techniques. Commented Sep 27, 2012 at 15:22

In my experience, one gets better results approaching embedded system software development with a "software developer" hat rather than an "electronics engineer" hat. (practices like TDD & CI are less common in hardware engineering)

On the other hand, I think that the experience of developing for an embedded system makes one a better; more well-rounded software developer.

  • 2
    Exactly, embedded developers here, the industry needs more cs people here, as software is getting much more complicated, we are really bad at good software quality practices. Commented Sep 26, 2012 at 15:07
  • I think the CS people would enjoy it also, as writing embedded software is one of the most rewarding (intellectually, if not financially) jobs that a software developer can do. Commented Sep 27, 2012 at 15:25

I was in a similar situation about 8 years ago. I had at that point 7 years of software development in application and server environments. My only experience dealing low level with hardware before had been writing in Z80 assembler as a teenager on a ZX spectrum.

It was certainly a challenge. I found dealing with the chip sets in assembler very enjoyable and I certainly learned a lot about hardware. A substantial part of my role was in testing the hardware using software, so learning to cope with programming and recognising that your software bug is actually a hardware bug. Actually sometimes it can take quite a bit of work by software and hardware people to identify if a bug is hardware or software.

One aspect that I failed to deliver on was device driver work. I never really grasped this, which is one thing that myself and that company director never understood why. It just became an accepted fact.

Becomming familiar with an occiloscope and a soldering ion will be essential. remembering that when a hardware guy says the number 26 he ALWAYS means 0x26 is useful. Realising that Hardware engineers find dealing with software very frustrating helps, but then, a hardware project that doesn't involve software is called a cable.

I stayed in that role for 4 years and only left because I was poached for a really fantastic opportunity.

  • Thanks for sharing your experience Ptolemy. I appreciate it.
    – Jeremy
    Commented Nov 30, 2010 at 21:51
  • Nowadays quite a lot of cables have microprocessors in them as well. :-) Commented Sep 27, 2012 at 15:28

Like everything, it requires a balanced approach. I love working with embedded systems at my day job. They make me better at electrical engineering. Physical computing and automation are very exciting. On the other hand, building web apps and tinkering with cloud computing is awesome.

If you do it right, the software side of you will look for ways to do things smarter and better. The hardware side of you will keep you mindful of resources and super efficient.

  • Thanks for your answer. I do see it as being able to shift fields a bit, if nothing but to learn the lower levels and then move back up the stack a bit.
    – Jeremy
    Commented Nov 30, 2010 at 14:38

I am not an Electrical Engineer, yet I have done a small amount of embedded software development. The biggest issue I've found is that I have a much more basic background in math, and so I don't know how to easily break down a complex series of advanced mathematical algorithms into code without a lot of help.

For all of the stuff where I've needed to play with signalling, read values from inputs, submit data to outputs, and all that sort of stuff, I've found it little different conceptually to what I do day to day as a good old fashioned Software Developer. Writing software really is what it is. It's when you need to go out beyond the actual software that I find things getting dicey because I don't have the knowledge to mess directly with the hardware. This usually happens when trying to debug or test code. If you've got a really great tool chain, you might have integrated debugging and simulation environment to take most of the pain away, yet even with all of that to help you, you sometimes need to get back to basics and test your code against some sort of an analyzer, and the reality is that most embedded platforms don't provide you with the luxury of more than a basic compiler and an EE's Ouija-Board to help you.

From this perspective, I don't think that being an electrical engineer is essential to embedded programming if the tasks are simple, and the actual hardware-specific requirements are minimal. Beyond that, I think being an EE would make life much easier when working in an embedded environment, particularly when real science is required to figure out where the problems are.

  • "EE's Ouija-Board" - brilliant, I know it well Commented Jan 27, 2012 at 5:30

I haven't done any business level embedded programming, but my Bachelor's was mostly about embedded systems, from which I have a few years of real experience. We used C on Atmel AVR and touched some Texas Instruments chips with VHDL, and had some theoretical stuff on ARM.

In what we had, it was roughly 50-60 percent programming (C), 20 percent planning/design (UML), and the rest was physical electronics (soldering, measuring, wiring, making cables, etc). I also agree it was very interesting and fun to do, and I actually wish I would also have a career in embedded systems. Alas, with a very small market in embedded systems, I had to resort to plain old Java EE.

But I digress; I would say the above mentioned percentages are quite close to real world jobs, since our teachers have their own enterprises, and also mentioned they will try to make it as realistic as possible. We even had random 180 degree turns in requirements mid-project, heh heh.

As for the stack. Knowing embedded programming will give you vast chances for creating your own and very real hardware products that you could have manufactured in real plants in Asia, then assembling them at your premises (be it at home or at your own company). It's highly interesting! You can also make many gadgets that will be helpful at home, such as movement controlled houselights, timer for a coffee machine to automatically prepare your morning joe, and so on. Exciting stuff indeed!

Not the answer you're looking for? Browse other questions tagged or ask your own question.