A bit of context

Most of the embedded, real-time systems developed by Fen have used FreeRTOS. FreeRTOS is a lightweight, open-source OS that provides the essential features – task management, scheduling and inter-task messaging – required to get multitasking software systems up and running on really skinny hardware. And by ‘really skinny’, I mean MCUs with RAM and ROM measured in K-bytes, not M-bytes, able to read and write sensors and actuators in real-time and to manage a wireless comms interface (or two).

MCU and SOC vendors such as Nordic, NXP and STM all provide some level of support for FreeRTOS in their SDKs. Over the years, we’ve tweaked our implementation, developed utility functions and integrated various comms libraries from a range of chip vendors. So now, after almost twenty years, we have a FreeRTOS-based development environment that fits, hand-in-glove, with the kind of rapid-turnaround IoT projects in which we specialise.

However, having seen growing support for Zephyr OS among the MCU and SOC vendors with whom we regularly work, we decided in early 2023 to take a close look at this alternative RTOS.

Zephyr

Like FreeRTOS, Zephyr is an open-source RTOS that targets low-powered embedded applications. Backed by the Linux Foundation, it provides the essential task management, scheduling and communication features you would expect. But it also goes quite a bit further. It is probably better described as a platform for embedded systems that incorporates an RTOS. It also includes a comprehensive set of ’stacks’ for comms, crypto and file systems, a software configuration framework (Kconfig), a hardware description framework (Device Tree) and an established build environment (West, Cmake).

Pre-integrated stacks

Comms stacks that come pre-integrated with Zephyr include Bluetooth, Wi-Fi, 802.15.4, LoRa, CAN, MQTT, OpenThread, CoAP, IP v4 & v6, USB up to USB-C and even Ethernet. Also included are a FAT file system and LittleFS (which is especially suited to super-constrained hardware), and a powerful command line interpreter.

K for configuration

The immediate concern with such a fully featured system is memory bloat. Isn’t there a danger that code footprint is massively inflated to support features that oftentimes won’t be needed? This is where we see the first nod to Zephyr’s Linux Foundation heritage. Zephyr’s build system includes a Kconfig utility which provides a mechanism to declare which modules should be built into an instance of the system. Although Zephyr’s Kconfig syntax and file naming convention is not the same as that used by Linux, the role of the respective Kconfigs in analogous. But is it effective? On the face of it, yes, because a de-featured instance of Zephyr has a memory footprint comparable to FreeRTOS.

Inter-thread messaging

Another nod to the Linux Foundation is seen in Zephyr’s ZBus. Somewhat analogous to the Linux D-bus, ZBus is a publish-subscribe messaging interface for inter-process (or task, or thread, depending on your dialect) communication. It’s more sophisticated than the FreeRTOS message queue and quite configurable. Listeners (simple call back, kicked off by the event dispatcher), Subscribers (who receive notification of messages) and Message Subscribers (who receive their own copy of messages) can all observe the ZBus. However, if there is a profound difference when compared with FreeRTOS it is that you can’t submit to the ZBus from within ISRs. This is quite a limitation, demanding the use of semaphores or other mutex mechanisms in certain situations which, in turn, become more difficult to log and debug than messaging-only systems.

Device tree for hardware independence

The Linux kernel comes with driver support for a huge array of devices. FreeRTOS often requires you to ‘roll your own’, although silicon vendor SDKs / BSPs will generally provide the chip-specific essentials. This isn’t too surprising. The worlds of fully-commercial hardware peripherals for ‘real’ computers and lashups based on a variety of silicon vendor dev boards are hardly comparable. However, this is one area in which Zephyr holds particular promise. In what is, once again, a rather Linux-like fashion, Zephyr makes use of a Device Tree to describe the hardware configuration of a system. The tree-like data structure – created in a human-readable Device Tree Source and compiled into a Device Tree Blob – provides a way to describe the hardware components, their interconnections, and their properties in a standardised, device-independent manner. This allows the Zephyr kernel to be hardware-agnostic, enabling it to run on a variety of architectures and platforms. To a single product-line or product-family business with massive investment in embedded software, this degree of hardware independence is potentially really important. To a consulting firm, developing multiple products on, generally, custom hardware platforms, there is for sure some value in this hardware independence but perhaps not quite as much as for the product business.

In late-2023 more than 500 development boards were available with Zephyr device drivers pre-integrated and, given the heavyweight backing that Zephyr has received, we expect this to increase.

Build environment

Zephyr has an excellent build environment that revolves around West and CMake. West manages Zephyr’s repo and external dependencies such as third-party drivers. These dependencies exist in individual git checkouts managed by West. West also supports building and debugging the project, enabling a quick and easy setup. FreeRTOS is relatively independent of compiler and build system, meaning you should find it easy to integrate it into any development environment you wish. Zephyr relies primarily on CMake and make or ninja, and the number of supported compilers is quite limited. Therefore, you would probably need to build your project around the Zephyr environment. In contrast, FreeRTOS can probably be inserted into your project regardless of your development environment.

Our own experience

We did some off-the-clock experimentation with Zephyr in early 2023 and it required quite a bit of adjustment. There was a new code base, new config tools, and a new build system to get to grips with. Of course, you do some things the way you do because you’ve always done them that way. Not necessarily because it’s the best or only way, just ‘because’. Adopting new methods may be uncomfortable not because those methods are bad or wrong but simply because they’re unfamiliar. Some things felt like more of a faff – allocating GPIO pins for example – but there are probably downstream benefits to be had from the formality.

So, yes, there’s a learning curve and some new philosophical approaches but, by way of example, incorporating OpenThread networking, IPv6 security and USB connectivity in a small monitoring project was close to trivial. And the developer support available online is excellent.

Since then, we’ve run several fully-commercial projects using Zephyr. Bottom line? We’re pleased with software productivity, even before making any allowance for the fact that the team is getting to grips with a new system.

In fact, for us, if there’s a killer benefit to Zephyr, it’s not the Linux-like ZBus (with its not-for-ISRs limitation), or the Linux-like Device Tree (which is of some, but not infinite, value in our world of largely custom hardware) that clinches it. The features that have really pushed productivity are the pre-integrated stacks and the excellent support available online from the worldwide developer community. On both those fronts, we can expect more progress as the platform matures and adoption increases.

Will we use Zephyr exclusively from now on? No. As always, we will focus on the technology set that best serves our specific client-and-project needs. FreeRTOS will still have a place but, certainly for IoT projects, Zephyr looks set to serve us well.

PS Yes, I know that Zephyr is not ‘hot air’ but the personification of the gentle West wind. However, you read this far, so the poetic licence in the headline was, I think, justified!