Four years of Zephyr

The Zephyr project is an effort to provide an open-source realtime operating system (RTOS) that is designed to bridge the gap between full-featured operating systems like Linux and bare-metal development environments. It's been over four years since Zephyr was publicly announced and discussed here (apparently to a bit of puzzlement). In this article, we give an update on the project and its community as of its v2.3.0 release in June 2020; we also make some guesses about its near future.

The authors are both Zephyr developers working for Nordic Semiconductor; Cufí was the release manager for the v2.3.0 release.

A Zephyr primer

While Zephyr can scale up to much larger systems, a typical target for the RTOS is a microcontroller without a memory-management unit (MMU) that has a sub-100MHz CPU, 512KB or less of on-chip NOR flash memory, and 32 to 256KB of built-in static RAM. Like the Linux kernel, Zephyr is configurable using the Kconfig language, and uses devicetree to describe hardware.

Unlike other RTOS choices, Zephyr is much more than a kernel. It's an RTOS with "batteries included". The project aims to provide all the software needed to develop, release, and maintain a firmware application. This includes a toolchain with compilers as well as flash and debug tools. The zephyr repository includes the kernel, protocol stacks, drivers, filesystems, and more. Upstream Zephyr also includes code from dozens of other third-party projects pulled in by a tool called "west". These include cryptographic libraries, hardware-abstraction layers (HALs), protocol stacks, and the MCUboot bootloader.

Zephyr is a library operating system. Its build system combines the application, kernel, and any additional code into a single, statically linked executable, all in a single address space (most microcontrollers do not have MMUs anyway). Each image targets a specific board, and is typically executed in-place from flash. Because of this, almost all configuration is done at compile time. Buffers are statically pre-allocated. The entire devicetree is accessible at build time, so a fixed set of devices and drivers are compiled in. This minimizes image size and maximizes information stored in flash, thus saving precious RAM.

Some features are tailored toward the fact that Zephyr can't self-host, so Zephyr developers build the whole "distribution" alongside the application. For starters, it has a cross-platform build and configuration system based on CMake and Python. This runs natively on Linux, macOS, and Windows, thanks in part to the fact that both Kconfig and devicetree are handled in Python 3 instead of the original Unix-only tools. This is critical since Windows is the most widely used OS for microcontroller firmware development.

More details

The Zephyr kernel supports multiple architectures and scheduling algorithms. There are cooperative and preemptive threads, along with facilities for reducing interrupt latencies and guaranteeing the execution of key threads. An optional user mode can use the Memory Protection Units (MPUs) typically present in microcontrollers to isolate and sandbox threads or groups of threads from one another and the kernel.

Zephyr supports six major architectures (x86, Arm, ARC, NIOS II, Xtensa, and RISC-V) and also runs in emulation. Both 32- and 64-bit processor support exists for some architectures. Within the Arm architecture, the emphasis has been on the usual 32-bit Cortex-M cores, but experimental support for Cortex-R and Cortex-A (including 64-bit Cortex-A) exists and continues to improve. Beyond "real hardware," Zephyr runs on QEMU, and as an ELF executable. It supports a simulated radio, which can save time and expense when testing and debugging radio frequency (RF) issues. In all, there are upstream support files for over 200 "boards".

Zephyr has logging and shell subsystems. These have configurable transports, including traditional serial ports (for both) and over the network (for logging). Logging is optionally asynchronous; in this case, a separate thread actually sends log messages. The logging calls themselves post compact messages to a queue, which can be done quickly, so logging can be done even from within interrupt context.

Hardware-specific APIs are built around a lightweight device driver model that is tightly integrated with the kernel. It supports a wide range of peripherals and sensors under this common model. Multiple storage options are available. These range from basic key-value storage optimized for NOR flash to filesystems.

Zephyr's batteries also include various communication stacks. Its networking stack has BSD-like socket APIs and supports various protocols. Zephyr has a fully open-source Bluetooth Low Energy (BLE) protocol stack that runs on multiple hardware devices. It also has an 802.15.4 stack and supports the Thread protocol. Controller Area Network (CAN) and USB device communication are supported out of the box. Zephyr additionally supports firmware upgrades over many of these transports.

But why, though?

One common question about Zephyr is "why?" Why was it started, when there are so many RTOS choices already?

Microcontrollers have become more powerful and include more memory, cores, security features, and must support more complex protocols and communication stacks. Firmware complexity has increased markedly over the years. As a result, homegrown frameworks supplied by a single silicon vendor, whether built directly against bare metal or a minimalistic kernel, are increasingly difficult to develop and maintain. Zephyr aims to be a scalable solution to this problem, developed cooperatively in the open, that integrates all its functionality around a common set of APIs and primitives.

Zephyr is being used by various parts of its community at this point. As readers might guess, Zephyr's members are likely to be using it. Some silicon vendors also have Zephyr support. For example, supported hardware is available from members NXP and Nordic Semiconductor. STMicro has also contributed code for some SoCs and sensors, and has been responsive to users. Various other architectures and boards are supported. Finally, there is an active open-source community, which we'll get into a bit more in the next section.

Who's behind all of this?

Zephyr is a Linux Foundation project with a paid membership and governance structure. It is, however, developed openly. Anyone may use and contribute to Zephyr without becoming a member — many do.

The project's members include silicon vendors, device makers, engineering organizations, and others. Funding is used, among other things, to pay for continuous integration, web hosting, marketing, and other infrastructure. Members receive voting seats on the project's Technical Steering Committee (TSC), and its Governing Board is comprised of members only.

Given that, it might be tempting to look at the project as simply a pay-to-play industry organization, but that wouldn't be a fair assessment. At least where the code and other technical contributions are concerned, Zephyr is a true open-source project. Patches and reviews are open to all. The core Zephyr repository is Apache 2.0 licensed, and contributors retain copyright over their contributions. In the v2.3.0 release, about one in four commits came from emails that weren't from member-owned domains.

The project's meetings, including the TSC's, are largely open for anyone attend and participate in — alas using a proprietary videochat platform — and have open minutes that are sent to the mailing lists.

Zephyr development takes place on GitHub. Patches are sent as pull requests and non-security bugs are tracked as GitHub issues. Subsystem maintainers have overall responsibility for their areas. Maintainers must be approved by the TSC, but maintainership is open to all, not just project members, and there are maintainers who are not from member organizations.

The project has open user and developer mailing lists with searchable archives; chat is currently done via Slack. See this help page for more details.

Wrapping up

Beyond expanding and improving what it currently supports, Zephyr will not stay still when it comes to adding features. In particular, the next release, which is currently scheduled for September, is targeted to include the following: Bluetooth advertising extensions, a thorough rework of its device model, improvements for MMU-based systems such as demand paging, initial support for a new TCP stack, and improved toolchain support for both proprietary toolchains and LLVM.

As we've seen, Zephyr's niche lies somewhere between bare-metal and full-featured operating systems. While relatively young in its current form, Zephyr is moving quicky and has accomplished much. The project has broad ambitions, and aims to provide a soup-to-nuts menu for firmware development. With that, we hope to have resolved any remaining puzzlement — and perhaps to see some more LWN readers saying hello and giving Zephyr a try.