Zephyr RTOS (official documentation)

The Zephyr Project’s own documentation — Apache-2.0, with some imported components under other licences. This is the spoke’s first T1 source and its first firmware source of any kind; until now the corpus was five vendor pages describing hardware, with nothing about the software that runs on it. Ingested via the 2026-08-05 research pass against growth edge #3.

Zephyr describes itself as “based on a small-footprint kernel designed for use on resource-constrained and embedded systems”, spanning environmental sensors up to IoT applications.

What it actually commits to

Breadth over any single chip. 10+ instruction-set architectures — ARM Cortex-M/A/R, x86, RISC-V, MIPS, ARC, Xtensa, OpenRISC, Renesas RX, SPARC V8. That list is the interesting part: it crosses the whole spectrum embedded-systems describes, from the bare-metal MCU rung to application-class cores, under one kernel.

Scheduling is where an RTOS earns the R. Cooperative and preemptive multi-threading, timeslicing, Earliest Deadline First, and meta-IRQ scheduling. EDF is the tell — a scheduler that orders work by deadline rather than by fixed priority exists for exactly the real-time-deadline constraint that embedded-systems names as one of the field’s five limits.

Memory protection on a device with no MMU. Configurable stack-overflow protection and thread-level memory protection on x86, ARC and ARM, alongside support for monolithic images where the part is too small for anything else.

The hardware is data, not code. Boards are described in devicetree and configured through Kconfig, built with CMake (≥3.28.0) and driven by west, which manages the workspace, the SDK, the build and the flash step. A target is named at build time — west build -b <board> — and gets granular for multi-core parts (nrf5340dk/nrf5340/cpuapp selects one cluster of one SoC of one board).

The claim this source lets the spoke stop taking on trust

The spoke’s standing caution is that specs here are claims — three of four founding sources were vendor or author self-descriptions with no independent measurement. Zephyr does not fix that for hardware, but it changes the shape of one open question. iot-protocols recorded the middle tier as fragmented across Thread, ZigBee, Z-Wave and 6LoWPAN, each with an alliance owning its specification. Zephyr sits under that fragmentation and absorbs it: the same kernel builds for parts that speak different stacks, so the portability problem moves from the protocol layer to the driver layer, where a devicetree entry is the unit of work.

That is the first thing in the corpus arguing that fragmentation is survivable rather than disqualifying, and it comes from a project with no radio stack to sell.

What it does not say, and the honest limit on calling it T1

It is T1 because it is the project’s own reference documentation, not because it is disinterested — a project’s docs describe the project as its maintainers understand it. Three specific holes:

• No footprint figures. “Small-footprint” appears; a kilobyte number does not. The one quantity a reader would use to decide whether Zephyr fits a part is absent from the introduction.
• No board count. The docs point at a catalogue and tell you to run west boards; they do not claim a number.
• Certification is aspirational, and the docs say so. The security overview names Common Criteria and FIPS 140-2 as schemes the project might pursue, and describes threat modelling via STRIDE and CVSS, a security subcommittee, and vulnerability handling through GitHub security advisories. There is no claim of holding any certification. For a spoke whose domain includes safety-relevant devices that gap is worth carrying: the process exists, the certificate does not.

The governing foundation is not named on the introduction page either, which is a small documentation gap rather than a substantive one.