Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

share|improve this question

closed as primarily opinion-based by MichaelT, durron597, Matthew Flynn, Kilian Foth, Bart van Ingen Schenau Oct 15 at 10:29

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

8 Answers 8

up vote 28 down vote accepted

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.

share|improve this answer
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 Heiler Nov 30 '10 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 Rowe Nov 30 '10 at 16:51
@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 Nov 30 '10 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.

share|improve this answer
Thanks for the 1-to-1 mappings AShelly. Knowing really nothing about the embedded work environment, it's good to know that. – Jeremy Heiler Nov 30 '10 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.

share|improve this answer
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. – William Payne Sep 27 '12 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.

share|improve this answer
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. – Bjarke Freund-Hansen Sep 26 '12 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. – William Payne Sep 27 '12 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.

share|improve this answer
Thanks for sharing your experience Ptolemy. I appreciate it. – Jeremy Heiler Nov 30 '10 at 21:51
Nowadays quite a lot of cables have microprocessors in them as well. :-) – William Payne Sep 27 '12 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.

share|improve this answer
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 Heiler Nov 30 '10 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.

share|improve this answer
"EE's Ouija-Board" - brilliant, I know it well – Martin Beckett Jan 27 '12 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!

share|improve this answer

protected by Yannis Oct 14 at 7:57

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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