Is embedded programming closer to electrical engineering or software development? [closed]

Question

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.

Answer 1

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.

Answer 2

@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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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!