RTOS (real-time operating system)

The software layer between bare-metal firmware and a full OS: a scheduler with timing guarantees, plus the drivers and services a constrained device needs. The “real-time” part is not about speed. It is about bounded worst-case latency — a deadline the scheduler is designed to meet, rather than an average it usually beats.

That is why the layer exists at all in this spoke’s terms. embedded-systems names the real-time deadline as one of the constraints organizing the whole field; an RTOS is the piece of software whose entire job is that one constraint.

Where it sits on the spectrum

The spoke’s spectrum runs from a metrology MCU in milliwatts to an x86 SBC booting Ubuntu at 30 W. The RTOS occupies the middle and lower-middle:

• Bare metal — no scheduler, one loop, interrupts. Smallest and least composable.
• RTOS — threads with deadlines, a driver model, no MMU required. zephyr is the corpus’s instance.
• General-purpose OS — Linux on an SBC. Rich, and it makes no timing promise a control loop can rely on.

awesome-iot names the populated field here — Zephyr, FreeRTOS, ARM mbed, Contiki, Apache Mynewt — plus a language wave (MicroPython, TinyGo, Rust) attacking the same rung from a different direction. Only Zephyr is sourced so far.

The recurring design problem: describing hardware without recompiling the world

An RTOS targets thousands of boards that share almost no peripherals. The answer the corpus has seen is to make hardware data: zephyr uses devicetree for the board and Kconfig for the feature set, so adding a part is a description rather than a port. This is worth watching as more instances arrive, because it is the same fragmentation problem iot-protocols records one layer up, solved by declaration rather than by standardization.

Related

zephyr · embedded-systems · microcontroller · awesome-iot · iot-protocols