18 stations. 3 tracks. From embedded constraints, C and microcontrollers, through memory, peripherals, RTOS, interrupts, low-power and OTA, to a full edge-AI track: on-device model optimization, TinyML inference on microcontrollers, NPUs and the on-device AI product.
18 stations on 3 ladders, in order — each rung is written assuming the one above it. Mark them off as you go; your progress is saved in this browser.
0 / 18
Pick up at
Track 1 of 3
Embedded FoundationsStart here
6 rungs · ~6h · ends at Debugging Embedded.
0/6 done
1
The Embedded Mindset
Start here
F1 · Beginner · 35 min
Embedded engineering is programming computers that live inside things — sensors, appliances, cars, medical devices — where resources are tiny and constraints are real. Learn the mindset that makes it different from app or web development: limited memory and compute, no operating system to lean on, real hardware you can break, and code that has to be correct because you can’t always patch it. This constraint-first thinking is the whole discipline.
What "embedded" means
Resource constraints
Hardware you can break
Correctness over convenience
Build itA web dev is shocked their firmware can’t just allocate memory freely. Explain what changes when you have 64 KB of RAM and no OS.
✓ CheckpointName a convenience you would give up on a device you cannot reach after shipping, and explain what it buys you.
C is the language of embedded systems, and using it well on constrained hardware is a real skill. Learn pointers and manual memory, bit manipulation (setting and reading hardware registers), fixed-width types, and how C maps to what the hardware actually does. You’ll also learn why the abstractions higher-level languages give you are luxuries you often can’t afford here.
Pointers and manual memory
Bit manipulation and registers
Fixed-width types
How C maps to hardware
Build itYou need to set bit 3 of a hardware register without touching the others. Write the bitwise operation and explain it.
✓ CheckpointExplain why a plain int is the wrong type in a register definition, and what a fixed-width type guarantees that it does not.
The microcontroller is your computer, and you have to understand the hardware to program it. Learn the architecture — CPU, flash, RAM, clocks, and the peripherals — how to read a datasheet (the embedded engineer’s essential document), and the basics of the electronics you interface with. Being able to read a datasheet and reason about the hardware is what separates embedded from pure software work.
MCU architecture
Flash, RAM, clocks
Reading a datasheet
Basic electronics
Build itA peripheral isn’t working. Explain why "read the datasheet" is the embedded engineer’s first move, not the last.
✓ CheckpointOpen a real datasheet and find the maximum clock speed and the pin's electrical limits. If you cannot, you cannot yet program that part safely.
On embedded systems memory is scarce and mismanaging it is catastrophic — there’s no OS to save you. Learn the memory model (stack, static, and why dynamic allocation is often avoided), how to reason about and minimize footprint, and the classic bugs (stack overflow, buffer overrun, use-after-free) that in embedded can silently corrupt or hard-crash a device. Disciplined memory thinking is core embedded craft.
Stack vs static memory
Avoiding dynamic allocation
Minimizing footprint
Memory-corruption bugs
Build itWhy do many embedded codebases forbid malloc entirely? Explain the risk it introduces on a long-running device.
✓ CheckpointExplain why dynamic allocation is avoided on a device that must run for a year, and what fragmentation does over that timescale.
Embedded systems talk to the world through peripherals and buses. Learn GPIO (reading buttons, driving pins), the workhorse serial protocols — UART, I2C, SPI — and how to interface with sensors, displays, and other chips. Learn to debug a communication problem with the tools of the trade (logic analyzer, oscilloscope). Getting two chips to talk reliably is daily embedded work.
GPIO
UART / I2C / SPI
Interfacing sensors and chips
Logic analyzer / scope
Build itA sensor on the I2C bus returns garbage intermittently. List the first things you’d check, from wiring to timing.
✓ CheckpointJustify I2C over SPI for one sensor and the reverse for another, in terms of pins, speed and bus topology.
Embedded debugging is its own craft — often there’s no console, and bugs hide in timing, hardware, and memory. Learn the tools (JTAG/SWD debuggers, breakpoints on real hardware, logging over serial) and the techniques for the hard cases: intermittent faults, race conditions, and bugs that vanish when you attach the debugger. Patience and systematic method matter more here than anywhere.
JTAG / SWD debugging
On-hardware breakpoints
Serial logging
Timing and heisenbugs
Build itA bug disappears when you attach the debugger. Explain what class of problem that points to and how you’d chase it.
✓ CheckpointDescribe a bug that disappears when you add a print statement, and what that tells you about where to actually look.
When a system does several things at once, a real-time operating system (RTOS) helps you structure it into tasks. Learn the RTOS model — tasks, scheduling, priorities — and the primitives for coordinating them (queues, semaphores, mutexes) without the classic concurrency bugs. Understand when you actually need an RTOS versus a simple loop, and the trade-offs it brings. FreeRTOS and its peers are core embedded infrastructure.
Tasks and scheduling
Queues, semaphores, mutexes
RTOS vs bare-metal loop
Avoiding concurrency bugs
Build itTwo tasks both update a shared buffer and data corrupts. Explain the bug and the RTOS primitive that fixes it.
✓ CheckpointExplain when an RTOS earns its overhead over a bare-metal superloop, and name the concurrency bug it introduces in exchange.
Interrupts let hardware grab the CPU’s attention immediately, and they’re fundamental to responsive embedded systems — and a rich source of subtle bugs. Learn how interrupt service routines work, why they must be short and careful, the timing and latency concerns of real-time systems, and the concurrency hazards between interrupts and main code. Reasoning correctly about timing is a defining embedded skill.
Interrupt service routines
Keeping ISRs short
Latency and real-time timing
Interrupt/main concurrency
Build itAn ISR does heavy work and the system becomes unresponsive. Explain why, and what the ISR should do instead.
✓ CheckpointExplain why a long ISR is a bug even when it is correct, and what belongs outside it.
Many embedded devices run on a battery for months or years, so power is a first-class design constraint. Learn the sleep and low-power modes, how to architect firmware to spend most of its time asleep and wake only when needed, and how to measure and reason about energy budget. Squeezing battery life out of a device is a distinctive embedded skill with no equivalent in most software work.
Sleep and low-power modes
Wake-on-event architecture
Measuring energy
Designing to a power budget
Build itA sensor node must run a year on a coin cell. Describe the firmware architecture that makes that possible.
✓ CheckpointCompute a battery life from an average current draw and a capacity, then name the one wake event that would halve it.
Modern embedded devices are connected — to phones, gateways, and the cloud. Learn the common wireless options (BLE, Wi-Fi, and low-power WAN like LoRa), the trade-offs between range, power, and bandwidth, and enough networking to get a constrained device talking to the world reliably. Connectivity is what turns a standalone gadget into part of a larger system and an IoT product.
BLE, Wi-Fi, LoRa
Range/power/bandwidth trade-offs
Networking on constrained devices
Reliable connectivity
Build itA wearable must sync to a phone and sip power. Explain why BLE fits and what you’d trade against Wi-Fi.
✓ CheckpointJustify BLE over LoRa for one product and the reverse for another, using range, power and payload rather than familiarity.
A device in the field still needs fixes and features, so over-the-air (OTA) firmware update is essential — and getting it wrong bricks devices. Learn how OTA works, the safety mechanisms (A/B partitions, rollback, verification), and how to update securely so an attacker can’t push malicious firmware. Reliable, secure OTA is what makes a shippable product versus a prototype.
OTA update flow
A/B partitions and rollback
Update verification
Secure firmware update
Build itAn OTA update fails halfway on 10,000 devices. Explain the mechanism that keeps them from all bricking.
✓ CheckpointDescribe what happens when power is lost midway through an OTA update, and what makes A/B partitions the answer.
Testing embedded is hard — the code runs on hardware you can’t easily automate, and bugs involve timing and the physical world. Learn the strategies: unit-testing logic on a host, hardware-in-the-loop testing, simulating peripherals, and building the test rigs that catch regressions before they reach the field. Good embedded testing is what lets you ship confidently to devices you can’t easily recall.
Host-side unit tests
Hardware-in-the-loop
Simulating peripherals
Test rigs and regressions
Build itYou can’t reproduce a field bug on your desk. Describe a test setup that would let you catch this class of bug earlier.
✓ CheckpointExplain what you can test on a host and what genuinely requires hardware in the loop, and name a bug only the real device shows.
6 rungs · ~5h · ends at The Embedded & Edge-AI Career.
0/6 done
1
Why Edge AI
P1 · Advanced · 40 min
Running AI on the device itself — not in the cloud — is one of the biggest shifts in embedded, and it’s where the field is growing fast. Learn why edge AI matters: privacy (data never leaves the device), latency (instant response), offline operation, and cost. Understand what’s newly possible (keyword spotting, anomaly detection, vision on a tiny chip) and the hard constraint that defines it — doing machine learning in kilobytes of memory and milliwatts of power.
Edge vs cloud inference
Privacy, latency, offline, cost
What edge AI enables
ML in KB and mW
Build itA voice-wake feature must work offline and instantly. Explain why that pushes the model onto the device, not the cloud.
✓ CheckpointJustify inference on-device over a cloud call for one product, using a reason that is not cost.
Full-size models don’t fit on a microcontroller, so shrinking them is the core edge-AI skill. Learn the techniques — quantization (float to 8-bit or lower), pruning, and knowledge distillation — and the trade-off between model size, speed, and accuracy. Understand how to compress a model until it fits the device’s memory and power budget while keeping it accurate enough to be useful. This optimization craft is where embedded meets ML.
Actually running a neural network on a microcontroller is TinyML. Learn the frameworks (TensorFlow Lite for Microcontrollers and peers), how a model is converted and deployed to the device, how inference works within tight memory and compute limits, and how to integrate it into real firmware alongside sensors and the RTOS. Getting a model to run in real time on a tiny chip is the signature edge-AI achievement.
TFLite Micro and peers
Model conversion and deploy
Inference under tight limits
Integrating with firmware
Build itYou have a trained gesture-recognition model. Walk through the steps to get it running on a microcontroller in real time.
✓ CheckpointExplain what has to be true of a model before it fits in a few hundred KB of flash, and what you would cut first.
Increasingly, edge devices include dedicated AI hardware — NPUs (neural processing units) and other accelerators — that run inference far faster and more efficiently than the CPU. Learn what these accelerators do, how to target them from firmware, and the trade-offs of hardware-accelerated inference. As edge AI grows, knowing how to exploit on-device AI silicon is a rising, valuable specialty.
NPUs and AI accelerators
Targeting accelerators
Hardware-accelerated inference
When acceleration pays off
Build itYour CPU can’t run the vision model fast enough. Explain what an NPU changes and what you’d need to use it.
✓ CheckpointExplain when an NPU is worth the integration effort, and when the CPU was already fast enough.
Building a real edge-AI product means putting it all together: capturing sensor data, running inference reliably on-device, managing power and memory, and updating the model in the field. Learn the full lifecycle — data collection, on-device training vs cloud training, deploying and monitoring models on fleets of devices, and the safety and reliability concerns of AI running where you can’t easily intervene. This end-to-end view is what senior edge-AI work requires.
Sensor-to-inference pipeline
On-device vs cloud training
Model updates on fleets
Reliability and safety at the edge
Build itYour deployed model degrades as real-world data drifts. Describe how you’d detect and fix that across a fleet of devices.
✓ CheckpointDescribe how you would update a model across a fleet of devices you cannot physically reach, and what your rollback is.
Embedded is a durable, hard-to-outsource field, and edge AI is expanding it fast. Learn where the path goes — firmware engineer, systems engineer, embedded ML/edge-AI specialist, and hardware-software lead — and why the embedded-plus-ML combination is especially valuable and scarce. Understand how AI changes the work (it helps write firmware, but the hardware judgment and constraints remain human) and how to build a portfolio of real devices that proves you can ship.
Firmware / systems / edge-ML paths
Embedded + ML as a rare combo
AI’s effect on embedded work
A portfolio of real devices
Build itWrite the six-month plan that moves you from firmware engineer to shipping an on-device ML feature.
✓ CheckpointExplain why embedded plus ML is a rare combination, and which half you are currently the weaker at.
The common questions before you start — how long it takes, whether to follow it in order, and how it stays current.
How long does this roadmap take?
It runs 18 stations across 3 tracks — roughly ~17h of focused learning, plus the time you spend actually building. It is self-paced, so most people work through it over a few weeks, an evening or a single station at a time.
Do I have to follow the stations in order?
The tracks are ordered so each station builds on the one before, and following them start to finish is the intended path. But every station also stands alone — if you already have the foundations, jump straight to the part you need.
Is it free?
Yes. The whole roadmap, and every handbook, lab, and challenge it links to, is free and open — no sign-up and no paywall.
How is the roadmap kept current?
It teaches the durable fundamentals of the role first, then the tooling and the AI-era shifts on top — so most of it stays relevant as individual tools churn, and it is revised as the role itself changes.
Who is this roadmap for?
Anyone stepping into or leveling up in the Embedded Engineer role — whether you are switching in, early-career, or a senior filling gaps. Start where you are; the ladder shows what is left.