FreeRTOS

FreeRTOS is the most widely deployed small RTOS. The kernel is only a handful of C files, which makes it the best place to learn how a scheduler really works. You will see how a context switch saves registers on the stack, how the ready list is sorted by priority, and how a queue blocks a task until data arrives.

Once you understand tasks.c and queue.c, every other RTOS on this list becomes easier to read, because they all solve the same scheduling and synchronization problems.

Zephyr Project

Zephyr is a full RTOS ecosystem rather than a bare kernel. It supports hundreds of boards and borrows Devicetree and Kconfig from Linux, so the same driver code runs on boards from Nordic, NXP, ST, Espressif and many others. It also ships a complete Bluetooth Low Energy stack, networking, and power management.

Reading Zephyr teaches you how large firmware projects stay portable. You will learn how a board file describes hardware, how drivers bind to that description at build time, and how a professional project organizes tests and CI.

ESP-IDF

ESP-IDF is Espressif’s official framework for the ESP32 family. It wraps a modified FreeRTOS with Wi-Fi, Bluetooth, TLS, OTA updates, and a component-based CMake build system. It is the fastest way to learn connected-device firmware on cheap, widely available hardware.

Pay attention to how it runs FreeRTOS on dual-core chips and how its event loop decouples Wi-Fi events from application code. Those patterns carry over to any IoT product.

Apache NuttX

NuttX aims to be a small Unix. It implements POSIX and ANSI interfaces, so code that uses open(), read(), pthread_create() and file descriptors runs on a microcontroller. It even has a shell, NuttShell, and a virtual file system where drivers appear under /dev.

It is a great bridge for Linux developers moving into firmware. It is also the operating system underneath the PX4 drone autopilot, which shows it can handle demanding real-time work.

Mbed OS

Mbed OS combined an RTOS (built on Keil RTX), a clean C++ driver API and connectivity stacks for Cortex-M boards. Its DigitalOut, Thread and EventQueue classes are still a tidy example of how to wrap hardware in object-oriented C++ without heavy overhead.

RIOT OS

RIOT targets very constrained IoT nodes, devices with a few kilobytes of RAM running on batteries for years. Its strength is networking: it includes a full IPv6 stack with 6LoWPAN, CoAP, and support for low-power radios.

Study RIOT to learn how a network stack fits into tiny memory, and how a tickless scheduler lets the CPU sleep between events to save power.

ArduinoCore-avr

This is the code behind every Arduino Uno sketch. It is short and readable, which makes it ideal for a first look under the hood. You will see how millis() is driven by a Timer0 overflow interrupt, how analogWrite() configures hardware PWM, and how the serial port uses a ring buffer filled from an interrupt.

CMSIS_5

CMSIS is Arm’s standard interface for Cortex-M processors. Every vendor HAL for Cortex-M builds on it. It defines how the core registers (NVIC, SysTick, SCB) are named and accessed, provides the startup code pattern, and includes CMSIS-DSP for filters and FFTs plus CMSIS-RTOS as a portable RTOS API.

libopencm3

libopencm3 is a community firmware library for many Cortex-M families, including STM32, NXP LPC, and others. It is thinner than vendor HALs, so each function maps almost one-to-one onto register writes. That makes it an excellent study companion while you read a reference manual.

STM32CubeF4

This is ST’s official MCU package for the STM32F4 series. It contains the HAL and LL (low-layer) drivers, board support packages, middleware such as USB and FatFS, and hundreds of example projects for real evaluation boards.

Comparing the HAL and LL drivers side by side is one of the best lessons in abstraction cost: the HAL is portable and safe, while LL is lean and close to the metal.

MCUboot

MCUboot is a secure bootloader used by Zephyr, NuttX, ESP-IDF, and many commercial products. It checks a cryptographic signature on the application image before running it, and handles over-the-air updates by keeping two image slots in flash.

It teaches the most important rule of field updates: a device must never be left without a working image, even if power fails mid-update. The swap-and-confirm flow in Fig. 3 is how MCUboot guarantees that.

LVGL

LVGL (Light and Versatile Graphics Library) builds smartphone-style interfaces with buttons, charts, sliders, animations and anti-aliased fonts on microcontrollers with as little as tens of kilobytes of RAM. It only needs two things from you: a function that pushes pixels to the display and a function that reads touch input.

The source teaches partial screen redraws, dirty-area tracking and draw buffers, which are the techniques that make smooth UIs possible without a GPU.

LittleFS

LittleFS is a small file system built for raw NOR and NAND flash. It is power-loss resilient, so a sudden reset never corrupts the file system, and it spreads writes across blocks to avoid wearing out one area of flash. Its RAM usage is bounded and does not grow with the size of the storage.

The design notes are some of the best writing on copy-on-write data structures for flash. Read them even if you never use the library.

nanopb

nanopb implements Google Protocol Buffers in plain C, with no dynamic memory allocation. You write a .proto file, a generator produces C structs, and the library encodes them into a compact binary format that a phone app or cloud server can decode in any language.

It teaches you how to design firmware messages that can evolve over time without breaking older devices in the field.

Embedded Template Library (ETL)

The C++ standard library containers allocate memory from the heap, which many safety and real-time projects forbid. ETL provides fixed-capacity replacements such as etl::vector, etl::string, etl::queue and etl::map whose maximum size is set at compile time, so memory use is fully predictable.

It is a good way to learn modern C++ techniques like templates and constexpr applied to embedded constraints.

Unity

Unity is a unit-test framework for C made of a single source file and two headers. It runs on a PC or directly on a microcontroller, and offers assertions built for embedded work, such as checking integers in hex, bit masks and memory arrays.

Ceedling

Ceedling is the build system that makes Unity practical at scale. It finds test files, generates test runners, and uses CMock to create mocks from your header files automatically. With mocks you can test a driver’s logic by faking the HAL calls underneath it, so you never need the real chip for unit tests.

OpenOCD

OpenOCD (Open On-Chip Debugger) connects your PC to a microcontroller through a debug probe such as ST-LINK, J-Link or a CMSIS-DAP adapter. It speaks JTAG and SWD to the chip, programs flash, and exposes a GDB server so you can set breakpoints and inspect memory from your editor.

Reading its target and flash drivers shows exactly how a debugger halts a core and writes flash through the debug port.

Renode

Renode, from Antmicro, simulates complete embedded systems, including the CPU, peripherals, sensors and even multiple networked nodes. It runs your unmodified firmware binary, so you can test a full Zephyr or FreeRTOS build in CI without any physical boards.

Its Robot Framework integration lets you write tests like “send this UART input, expect this output”, which is how teams catch regressions on every commit.

QEMU

QEMU is the general-purpose machine emulator used across the industry. For embedded work it emulates Arm, RISC-V and other architectures, with machine models for boards such as the BBC micro:bit and several Cortex-M and Cortex-A platforms. Zephyr and many Linux-based projects use it as a default test target.

Compared with Renode, QEMU is faster and broader in CPU support, while Renode models more peripherals and multi-node systems. Learn both.