# Embedded Programmers: How deep down the EE rabbit hole? [closed]

So I know most Embedded developers are probably EE/CE with some CS sprinkled in. I've done....enough with Arduino to where I want to get closer to the hardware. I graduated with a C.S. degree, but have the desire to learn a lot more about interacting with memory/registers/etc...(im not sure if it'll ever get me a job....but it's more for personal knowledge)

However, im curious how far down most "embedded programmers" go. I mean electronics themselves is a deep field. I do want to know enough about interacting with memory/registers/etc.. (even in ASM). But.....would there be a need to go further?

Secondly, is this even a doable thing with a C.S. degree? I know most embedded jobs require an EE degree, but do any do C.S.?

If so whats the best way to move from something like arduino? Im not really looking to do stuff with say.....beagleboards or anything Unix related. Im really talking about REALLY low level (ARM/AVR devices and such). Enough to where i can interact with the memory/register components. (I feel like thats the closest level without having to know how to build the chip itself haha)

• It depends on what context. Designing an embedded architecture requires more low level knowledge than writing firmware for an established one. FWIW I work as an EE/Embeded Dev with a physics degree, same with my immediate superior – crasic Nov 5 '15 at 4:35
• Yeah I guess my end goal isn't to design architecture, I feel that probably belongs to EE's haha. But writing the code for an established one, and interacting with low level components (Registers/ram/etc...) seems maybe in the grasp of a C.S. major? – msmith1114 Nov 5 '15 at 4:36
• I would say that 90% of the interface with the EE side when writing embedded firmware is covered by the datasheets. If you can read and understand an IC or MCU datasheet the rest will be fine. At that abstraction level the hardware looks more like lego conceptually – crasic Nov 5 '15 at 4:38

I initially got a BSEE degree, and started designing logic circuits out of school. After a couple of years, I realized most of what I was doing could be done using microprocessors (this was back in the 1970's, when the first ones were just coming on the market). So I went back and got an MSCS degree. Ever since then I have leveraged the combination of the two in a successful career of embedded hardware design and programming.

Without some formal training, it is pretty hard to pick up enough electronics knowledge to design complex circuits from scratch; from my experience it's always seems easier to teach a EE to program than teach a CS major to design hardware.

That said, you can probably learn enough on your own to understand schematics of development boards etc., at least the digital portions. Analog circuitry (op-amps, amplifiers, power supplies etc.) is more of a black art, especially high-frequency RF (radio frequency) circuits. There's a lot of math involved; for example check out these equations for various kinds of filters. This is a far cry from digital logic where one works with Boolean algebra and things like Karnaugh maps. Since you're not going to be designing circuits, you just need a basic understanding of logic gates (AND, OR, NAND, NOR, XOR and NOT). You may also want to learn about flip-flops (which are used to make registers), multiplexers and de-multiplexers. These building blocks, along with memory, make up the guts of a microcontroller.

A book I highly recommend to start with is "Practical Electronics for Inventors"; forget the Inventors angle, it just plainly a good basic book on the subject. (Another book often mentioned is "The Art of Electronics", but it costs four times as much ($90 vs$22) and is quite a bit more theoretical.

Another book you might look into is "Code: The Hidden Language of Computer Hardware and Software", by Charles Petzold, who was a legend at Microsoft. It is fairly basic, but does do a nice job of showing how the hardware and software work together.

In terms of tools, you're going to want to get at least a decent multimeter, that can measure voltage, current, resistance, and maybe capacitance. One of the satisfying first steps in embedded programming is to be able to blink an LED using one of the port pins on a microcontroller. This is essentially the "Hello World" of the embedded world. You will find dozens if not hundreds of posts on this forum re this activity.

Eventually, if you want to get serious about poking around circuits, you will want to get a digital oscilloscope, perhaps 60 or 100 MHz.

As someone else said, one of the skills you will want to master is reading datasheets for the various parts on a PCB (printed circuit board); not just the microcontroller but also various peripherals like sensors, LCDs, modems (used for cellular, Bluetooth, and other communications), etc.

Since you have already worked with an Arduino, I suggest you step up from the 8-bit processor world to a 32-bit one. You will want to pick a particular microprocessor family and then get a development board to go with it. I'm going to suggest an ARM Cortex-M7 processor: the STM32F746NGH6. It is a RISC processor, like AVR32 and MIPS, running at 216 MHz. The processor has 1MB of Flash, 340K of RAM, and all the usual serial interfaces (I²C, SPI, UART, USB) plus up to 18 timers. You may or may not have encountered some of these peripherals on the Arduino. You will find that all of the hardware interfacing is done by writing into dedicated registers on the chip provided for each peripheral. Explaining all of these is what makes the datasheets so long (220 pages for this particular chip). You can obviously ignore some of the more complicated stuff like DMA and DSP until later.

There is a very nice evaluation board available for $50. It has a 4.3" touch screen LCD, 8 MB of additional RAM and lots of other goodies. In any case, you want to stay away from single board computers (SBCs) like the Raspberry Pi and Beaglebone Black; they are very capable and also inexpensive (you can get a Raspberry Pi for a little as$20). However they in general run Linux, and it is much tougher to get "down to the metal" on those because you have to deal with device drivers that fit into the Linux model.

I strongly suggest you try to write some assembly language programs, in addition to C, as it will definitely give you a better idea of what is going on under the hood. Plus it's just fun. The book "ARM7 Assembly Language Programming: 100+ examples" is only available as an eBook (Kindle), but you can download a Kindle reader for your PC if you don't own a Kindle.

If you program only in C (or some other high-level language such as C++, but the vast majority of firmware for microcontrollers is in C), you won't see any references to the processor's registers. You need to either program in assembly, or have a disassembler available where you can see the machine code the compiler is generating for you.

In addition, the book "Digital Design and Computer Architecture: ARM Edition" looks interesting since it covers both hardware design and ARM architecture. So you may be able to just use it as your initial hardware introduction. (You can click on "Look inside" for an of these books to see the Table of Contents and sample pages.)

• This is all super information, do you think it's near-impossible for just a C.S. grad to do ANY embedded work in the Embedded Career field? Im not looking to design circuit boards or anything, more-so just be able to program on these type of devices. – msmith1114 Nov 5 '15 at 20:02
• @msmith1114 Firmware engineers with or without a CS degree need to have a basic grasp of electronics, and be able to read schematics and use a digital multimeter, oscilloscope and maybe a logic analyzer, signal generator or arbitrary waveform generator. In addition one needs to be able to read and understand technical datasheets, some of which run into several hundred pages for a complex microcontroller with lots of embedded peripherals. In my last job with four firmware (only) engineers, each one had a digital multimeter, oscilloscope and power supply on their desk. (con't) – tcrosley Nov 5 '15 at 20:47
• @msmith1114 You can learn to read schematics from the books I linked to in my answer. The instruments are best mastered by reading the manuals or having someone else show you. You really only need to use the instruments I listed if you are debugging a new board or verifying modifications made to an existing board. If you are just using a development board, it's still useful to have access to an oscilloscope to verify various signals on the PCB. The really long datasheets can be pretty daunting; you need to be able to filter the information to find what you need and ignore the rest. – tcrosley Nov 5 '15 at 20:58
• @msm The nice thing from a programmers' standpoint is digital logic uses primitives such as AND, OR, XOR and NOT, and virtually all programming languages have the same logical operators (&, |, ^ and ~ in C). So one is already familiar with them. You'll see a lot of NAND gates, which is just an AND followed by and inverter, and NOR gates, an OR gate followed by an inverter. If you take a look at a typical schematic, you'll actually not see very much discrete logic (i.e. separate gates) anymore except for maybe some address decoding. So the material in the books I mentioned should do just fine. – tcrosley Nov 6 '15 at 5:42
• @msmith1114 MSP430 is a good processor family for embedded systems, especially ones running on batteries since it uses very little power. Have fun! – tcrosley Nov 6 '15 at 20:59

I'm in a similar boat to you, and I just started picking up avr programming. I'm sure you would know c at this point, so all you need to do is start reading data sheets. If you want to stick with atmel, I would suggest getting an avr dragon, just for the price and getting debugging features built in. The data sheets go over all the registers on what controls what, and if you have done anything with arduinos, it should look somewhat familiar. I just picked up a book "programming and interfacing atmel avr microcontrollers" by Thomas grace. Really helpful stuff, and starts off with assembly (assuming you know none, it is helpful with that) and then has c alongside the assembly code in later examples. There are a vast amount of examples in the book as well, it appears like a great resource. In terms of jobs, I can't help you out there; only set you on a path that I started paving myself to learn this stuff. It isn't that bad when you get down to it. Wish you luck in your adventures

• Are you able to interact directly with registers/memory etc? or do the books not really get into that much detail. – msmith1114 Nov 5 '15 at 5:10
• That is all the book is talking about. And it does explain things in a rather nice detail, plus it is an easy read. I was able to get through about 80 pages after picking it up today. It's around 300 pages, so not that bad. Definitely a good place to start. I found a lot of online sources were confusing, as they didn't explain what was going on. This book starts off with some electronics, then logic gates, then goes into assembly. Then mixes in some c, and then onto practical examples like adc, spi, usart, motor control, running leds, etc. – bit0fun Nov 5 '15 at 5:13
• Out of curiosity is your background CS or EE or something else? – msmith1114 Nov 5 '15 at 6:30
• Well, I'm in undergrad for mechanical engineering, but I teach myself electrical for fun. – bit0fun Nov 5 '15 at 11:22

I started in hardware before the concept of embedded programming was common (1970), so I started doing code on a ZX81 with the 64k Rampack (after all, who could possibly use up all of 64k of memory?).

I acquired a Altair 8800 kit and some expansion boards and started playing at toggling bits, implementing things like a UART and the (standard at the time) audio cassette interface for programme storage.

Datasheets at the time were harder to acquire (be very grateful for the internet!) so much of what I did was truly trial and error, but I managed to avoid blowing anything up.

Certainly, even if you have a RS232 interface on your kit (which allows you to specify the protocol, which is not really part of RS232 but is universally present), learning how to implement one by bit banging will definitely get you acquainted with the details of the hardware.

As TCrosley mentioned, the datasheets for the peripherals attached to the controller are just as important as you need to make those things work together, a task an order of magnitude more complex.

Over the years I have written at different levels, including my own device drivers for IRIX, Solaris and even Windows.

The point is that a deep understanding of the hardware permits us to do more with the hardware, by understanding the limitations of it.

I am currently using a Silicon Labs Wonder Gecko kit (now \$29.99) in a research project for ultra low power applications. There is a free Eclipse based IDE, compiler, libraries and lots of example software.

This is an interesting part as it has numerous autonomous peripherals within the package on the die, so this is a powerful platform to learn about interrupts, DMA handlers and more.

I also work quite extensively with PowerQUICC III and QorIQ processors; calculating the register settings for a DDR2 / DR3 interface will really give you an idea of some of the deepest embedded tasks possible; If there is a datasheet more convoluted than that for a processor, it is DDRx (and the many application notes from Micron that are an incredible source of good information).

I find doing hardware and embedded code to be fun because there is always more to learn as new processors and peripherals become available.

I agree with your basic tenet that a hardware focus is a better starting point, but learning about the hardware will give you new insights into just how to structure code to get the most out of it. Most of the device driver people I know started as EE or physics majors.

Have fun!