5 Steps to Getting Started with Embedded Programing

I’ve been getting asked the question, “So how would I get started with embedded development?” more and more often lately.

This is actually a really tricky question. It’s not like, “How would I get started with Haskell?” or “How would I get started with Rust?” Embedded development is such a weird and diverse thing that it’s almost like asking, “How do I get started with programming?” except in an alternate universe where 128k is still a lot of RAM. I’m not sure where to even begin.

I think the people asking have one of two goals:

1. “I want to make my software affect physical things.”
2. “I want to learn what’s actually happening way down there at the bottom.”

If you’re mostly interested in the first goal, then I would recommend you check out the many good hobbyist embedded platforms available now (Arduino, Raspberry Pi, Particle, etc…). They have lots of great communities to participate in and learn from.

However, if you’re more interested in the second goal, your task is a bit harder.

1. Learn C

For a variety of reasons, the vast majority of embedded toolchains are designed to support C as the primary language. If you want to write embedded software for more than just a few hobbyist platforms, your going to need to learn C (and hopefully maybe eventually Rust).

2. Learn Some Basic Electronics

Don’t worry, you don’t need to take a class or anything. You just need a basic understanding of voltage, current, power, resistance, ohms law. You probably can get by with just a few online tutorials and some experimenting with online simulators and/or real circuits.

3. Get the Basic Equipment

Since this is embedded software and you’ll actually be interacting with the physical world, you’ll eventually need some physical equipment. You’ll at least need:

• Soldering iron
• Digital Multi-Meter (DMM)
• A hardware debugger/ JTAG adapter (such as an ST-Link, or OLMEX adapter)

I also highly recommend getting a Logic Analyzer. My favorite is from Saleae, but they are many other cheaper ones.

4. Choose a Microcontroller and Toolchain

Okay, so now that we have the fundamentals, can we get to coding already?!

Almost. To actually get your programs running, you’ll need a microcontroller to run them, a compiler that can compile your programs for your target microcontroller, and other tools to load your programs onto your hardware and debug them.

I personally like the STM32 family of microcontrollers. They are well supported by my favorite embedded toolchain: arm-gcc along with openOCD. This combination is not as user friendly as an Arduino, but it’s also suitable for many more real-world applications.

• One good starter option is to get an STM discovery kit; they are cheap, relatively accessible, and easy to get started with.
• ARM is by far the most common architecture for embedded micros (especially 32bit micros), and arm-gcc can target pretty much all of them.
• openOCD is an open source piece of software what will communicate with a hardware debugger and provide a gdb debugger server so you can load a program and step through your code running on target with gdb. You don’t even need to run openOCD on the computer you’re developing and running gdb on.

5. Pick Components & Dig into Their Datasheets

Now you have enough to actually get started on something. All you have to do is pick out some components and then put them together! Some good places to look for components are sparkfun and adafruit. And for broader and cheaper selection, also digikey and mouser.

Once you’ve found a few components that you think will do what you want, you’ll have to dig into their datasheets. Datasheets are essentially the manuals for electronic components. They are the key to figuring out how to use a component and to make sure it will, in fact, work for you application. Most of the questions you have about a component can be answered by its datasheets. But datasheets can be tricky. Tricky enough that I have my own 3 rules of embedded programming:

• 1st rule of embedded programming: Read the datasheet.
• 2nd rule of embedded programming: Read the datasheet.
• 3rd rule of embedded programming: Don’t trust the datasheet.

Datasheets are the source of all knowledge, but also not entirely intuitive or even accurate. I recommend reading how to read a datasheet and Sparkfun’s datasheet tutorial to help get started.

Whew, that’s quite a lot to go through, but will give you a pretty solid basis when you actually get through it. :)