Zephyr

Zephyr can feel heavy when first encountered.

Blinking an LED may involve a board definition, devicetree, overlays, Kconfig, CMake, west, and driver bindings. Compared with direct register code or a vendor HAL call, the path looks indirect.

But Zephyr is not mainly about making a tiny demo run. It is better understood as a platform engineering model for multi-board, multi-configuration, long-lived, connected embedded devices.

The first model is:

lightweight RTOS: application organized around kernel objects and SDKs
Zephyr: application organized around configuration, hardware description, driver model, and subsystems

If the project has one board, a few peripherals, and a short life, Zephyr may feel costly. If it must maintain boards, feature variants, and shared drivers, the structure starts to matter.

When an MCU project chooses an RTOS for the first time, the first questions are often about size, speed, and API simplicity.

Those questions help, but they are not enough. Choosing an RTOS is not only choosing a scheduler. It is choosing how device software is organized: how tasks are created, how drivers are integrated, where networking and filesystems come from, how board differences are maintained, whether existing C or POSIX-style code can be reused, and whether the team can debug field failures.