Today marks the general availability of a new version of the Zephyr Project, Zephyr 4.1, and as always it is packed with new features and general improvements.
This article will dive into some of the most interesting highlights of the release and, as is now a tradition, I have prepared an accompanying video that shows some of said highlights in action. Make sure to also check it out to get additional explanations and demos!
As you read through the article, clicking on the ▶️ symbol will take you to the section of the video that shows the feature in action.
Also, be sure to mark your calendars for our next Zephyr Tech Talk on Thursday, March 20th, where some of the people behind the changes covered in this article will join me to discuss their work, roadmap for Zephyr 4.2 and beyond, and answer all your questions!
The merge window for Zephyr 4.2 will open shortly, and there are already hundreds of pull requests ready to be merged!
▶️ Performance Improvements
Zephyr’s feature set is so extensive that it is all too easy to forget it’s fundamentally a real-time operating system. While the project team works hard to provide a robust ecosystem of drivers, subsystems, and pre-integrated libraries, etc. it’s critical that all these elements rest on a solid foundation—namely, a kernel that delivers optimal performance across all supported targets.
Performance and efficiency are usually quite important in the embedded world, and one usually expects to get the most of their tiny (or not so tiny!) microcontroller. And while pure performance is only one of the many factors that should make you pick a particular RTOS, it is still important to have at least a rough idea of how it performs so you can be confident your application will “fit” on your chosen hardware.
Over the past few months, and even before the 4.1 release cycle started, a lot of work went into identifying and fixing some performance bottlenecks in the kernel, as well as adding more tests to our existing benchmarks to better assess the performance of the Zephyr kernel, and how it compares to other real-time operating systems out there.
An official port of the “thread_metric” RTOS benchmark has been added to Zephyr, making it easier for developers to measure Zephyr’s performance on their hardware and compare it with other RTOSes. This standardized benchmark suite tests various RTOS operations including thread creation/deletion, interrupt processing, and various synchronization primitives.
I don’t want to necessarily bore you with numbers and charts—plus, I am a big believer that performance of an RTOS is only one of the many factors when selecting/evaluating an RTOS!—but just to give you a sense of the work that went into improving the overall performance of the Zephyr kernel, check out the chart below. Zephyr 3.7, in light purple, is set as the reference (100%).
As you can see, performance has improved across the board since Zephyr 3.7 LTS was released in July 2024 and, as always with Zephyr, tweaking your compilation options can make even more of a difference. For example, here, enabling the use of a multi-queue ready queue can make cooperative scheduling much faster (hatched purple bars at the bottom of the chart) if that’s something you need and if you’re willing to trade this for potentially increased code size and RAM footprint.
Performance improvement since Zephyr 3.7 LTS
Thanks to these recent improvements, the previously observed performance gap with other open-source RTOSes has been largely closed.
The chart below shows Zephyr 4.1 as the baseline (in dark purple) and illustrates how Zephyr’s performance pretty much matches Eclipse ThreadX’s and surpasses FreeRTOS’s in most situations. With Zephyr now roughly on par performance-wise, it is actually a good reminder that performance is only one of the many aspects that should make you pick an RTOS over another anyway. Evaluating the community, the governance model, or the security practices, among other considerations, can be just as important.
Comparing other open source real-time operating systems with Zephyr
▶️ Experimental support for IAR toolchain
The IAR Arm Toolchain can now be used to build Zephyr applications. IAR is a commercial suite of compilers and development tools, widely recognized for producing highly optimized code.
To get started, simply set ZEPHYR_TOOLCHAIN_VARIANT=iar in your environment and point IAR_TOOLCHAIN_PATH to your IAR installation directory. The Zephyr build system takes care of the rest, and build options you’re used to using (ex. setting CONFIG_SIZE_OPTIMIZATIONS/CONFIG_SPEED_OPTIMIZATIONS based on whether you prefer a smaller binary or a faster one) will automatically map to the corresponding flags of the IAR compiler without you having to even think about it.
The support is experimental at this stage, but it will be really interesting to see it evolve and improve in future releases, and how it will help us improve the overall quality and safety of our codebase due to the sheer amount of code “smells” the compiler is able to surface.
▶️ Experimental Rust support
It is now possible to write Zephyr applications in Rust, thanks to an optional module that can easily be enabled in an existing Zephyr workspace.
This integration makes Rust’s strong memory safety and concurrency model available to Zephyr developers. Just as with the IAR toolchain support, this is still experimental, but excitement is already growing in the #rust channel on Zephyr’s Discord server. If Rust and/or Zephyr piques your interest, make sure to join the conversation
▶️ USB MIDI 2.0
Zephyr 4.1 introduces a new USB MIDI 2.0 device driver, essentially allowing developers to create Zephyr-powered music instruments! 🥁
The sample application that’s accompanying the driver is very easy to get up-and-running on virtually any board that supports the new USB device stack. Just flash the sample, open your favorite DAW, and start making music! In fact, this feature hasn’t even been part of any official Zephyr release (until today!) and yet, you can already find people online who have successfully adopted and extended this to build actual instruments!
▶️ 70 new boards supported, including Raspberry Pi Pico 2 and WCH CH32V003EVT
This release continues the tradition of adding support for dozens of new boards, across all processor architectures.
Notably, hardware enthusiasts and makers will be pleased to hear that Zephyr now has support for:
- Raspberry Pi Pico 2 and Pico W support: It took a lot of effort from several community members but the Raspberry Pi Pico 2 is one of the newly supported boards in Zephyr 4.1, and alongside it we also now finally have a driver for the Wi-Fi module in the W series!
- WCH CH32V003EVT: An ultra-low-cost (typically $0.10 or so!) RISC-V chip that’s gaining popularity in the maker community and that’s also one of the cool additions to the list of supported SoCs/boards in Zephyr.
Many new CAN+USB capable boards such as canbardo, Makerbase MKS CANable V2.0, FYSETC UCAN, and others are now supported and are great candidates for folks interested in running the Zephyr-based open source CANnectivity firmware for building USB-to-CAN adapters.
And more…
With a record amount of contributions and contributors for a non-LTS release, it’s virtually impossible to highlight everything (again, please make sure to check out the full release notes!) ; however, here’s a few more noteworthy items from this release:
▶️ Smarter shell commands
Thanks to recent efforts to make driver API structures available through iterable sections, most shell commands are now much smarter in terms of auto-completion and just nicer to use.
In other words, code completion for say the sensor get command will give you only sensors to choose from, where previously you would have been faced with the dozens of devices available in your system, no matter what type of driver API they were implementing.
▶️ Board catalog now allows you to search by supported hardware capabilities
We know there is still a lot to do, but we are hopeful that our documentation keeps getting incrementally better!
In Zephyr 4.1, we are introducing an extension to the board catalog that now allows you to search boards based on what hardware capabilities they support.
For example, if you are looking at putting together a quick prototype for an application where you will need a display, the ability to store data on an SD-card, and you’ve settled on using Arm architecture, you can very quickly enter these criteria in our board catalog and immediately know that there’s apparently 13 (at the time of writing!) boards that have what you need. Many of the boards’ READMEs have also transitioned to showing a list of supported features that’s automatically generated from Devicetree information, giving you a much more accurate snapshot of what is currently supported on the board.
If you enjoyed this article, don’t forget to subscribe to the Zephyr newsletter to receive insightful quarterly updates about all things Zephyr! You can also follow us on Twitter and LinkedIn.