Hacker News new | comments | ask | show | jobs | submit login

I'm an embedded software engineer. Here's my $0.02 on how to get started:

1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example.

2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on.

3. Learn what a programmer's memory-model is.

4. Learn what peripherals are, and what they do. You may have to dig a bit into basic electronics.

5. Learn what user-space vs kernel-space is.

6. Learn what device trees are, and how to prevent kernel from taking over a peripheral.

7. Based on above information, write a user-space driver for a simple peripheral (e.g. GPIO or UART) in C (don't try to learn assembly, yet). You will not be able to use the peripheral interrupts in user-space.

8. Learn how to verify hardware functionality, and see your driver in action. (Warning: high dopamine levels are reported at this point).

9. Repeat steps 7 and 8 for all peripherals, and see how far you can go.

> 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example.

I'd recommend something cheaper and simpler like the STM32F4 discovery boards. You won't get linux and will have to program via JTAG but the documentation for the STM32F4 is not as overwhelming as Broadcom's.

I like this suggestion. Their F3 disco boards are also nice.

For a related twist the OP might check out the Nordic Semi's M4 with radio SoC offering, the nRF52840DK. It has an onboard, breakout-able segger JTAG programmer and is easy to get going with Segger's freebie take on a GCC IDE.

Does knowledge of the STM32 family apply to other ARM chips?

Yes and no. Some of the general part features will be familiar (in the sense that an ARM Cortex M[X] is the same as any other Cortex M[X].

In reality every vendor's peripherals, and more importantly HAL and associated drivers and libs, will be different. But if you've done it once learning another vendor's way of life is a bit like learning a new programming language; it's just syntax.

Broadly most (IE communication, ADC, watchdog, etc) peripherals will be similar but there are definitely places where the differences will be larger. I'd expect those to be largely focused on clock trees, interrupt architectures, power modes, etc.

So short answer I agree with parent, get a cheap board and learn some stuff. If you like it, go from there. Do NOT choose a Cortex A though unless you want to really dig into embedded Linux. Systems at that level are way, way more complex and if the goal is to learn "everything about this processor" that will be especially difficult.

I would say absolutely yes. I started with the STM32 parts and have then used ARM Cortex devices from TI, Freescale, and Atmel. They all have different peripherals and of course different peripheral libraries from the vendor but overall they are conceptually similar. It can certainly be a pain in the neck to switch a project from one device to another (lots of gotchas with pin layout, peripheral minutiae etc etc) but starting a new project with a different device should not be too hard!

Except for the Kinetis DMA, I never understood that one!!

Spent a lot of time with the Kinetis DMA. Luckily I had nothing to compare it with. Learned later it was not as other DMA:s.

Yes and no.

General ARM programming--yes.

Specific peripherals--no.

General peripheral knowledge--yes.

An ARM is an ARM withing certain limits so your knowledge transfers. Sadly, every chip has a different way of programming the periperhals. However, every chip has roughly the same core peripherals (I2C, SPI, UART, etc.), and those electrical specifications and how you use them for protocols doesn't change.

  General peripheral knowledge--yes.
Maybe, programming a modern DMA based device running in a full blown OS with userspace, kernel space, an IO MMU, giving you bus IOVA addressing through a VM, with multiple command buffers, SRIOV, etc, while not wildly different isn't the same as doing IO read/writes into a fixed MMIO mapped device region. Doing some basic SPI programming is a start, but one has to understand there are a lot more layers that get added as the systems grows from a AVR level device to a modern server.

Emphasis on 8. If you are writing code that directly controls hardware, then your software is the abstraction.

Hardware is physical and can be quirky. Signals take real clock time to settle down and your CPU is probably much faster than the transition time. Hardware can and does have bugs just like software. A bad ground pin can make your hardware do “impossible” things.

You need to have much more awareness of the context your code runs in the further down the stack you go.

This is an odd ordering, mostly because of things like devicetree's are pretty arm/linux centric. In which case if your doing arm/linux just find a module you can unload or fail to build into your kernel. Real embedded programming is more like grab a cortex-m0, avr, etc and start bit banging.

OTOH, there is a danger that I've seen frequently that embedded systems guys don't seem to be able to make the conceptual leap to fully paged, SMP programming. Having sort of come up this way myself (via mircocomputers without MMUs and just a single processor) it doesn't make any sense to me, but it seems common.

People who have been exposed to a more common multi-threaded and virtualized environment seem to be able to pick up those pieces easier.

Oddly there is a Raspberry Pi 3 sitting on my desk today. I find myself a little reluctant to setup the BTD loop for it (BTD = build test debug), because at the end of the day I'm going to have a (physically small) linux box. Which is fine because I plan on installing a network proxy on it that only needs wifi. But how is the Pi a gateway to embedded programming? It has pinouts you can attach an oscilloscope to?

The hardware is better documented and less complicated than a full intel PC, I think is the general goodness to it. It's designed specifically to 'tinker' with.

Yes, it has a GPIO header that has pins that mux to a limited number of periphals. You can attach an oscilloscope to any GPIO.

10. Buy an oscilloscope learn to use it.

Great list. I would add, learn a little about a real-time OS, and become really good with a source code debugger.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact