Every four to five months we get a new release of Zephyr RTOS, and it is always my great pleasure to dig into what the community has been working on, and share some of the highlights with you. Today, I am thrilled to announce the release of Zephyr 3.7, a new significant milestone for the project as it is also the next Long-Term Support (LTS) release.
A lot of work goes into shipping a new release, and the Zephyr community has been doing this with a predictable cadence for the past 8 years. This predictability is a key factor in making Zephyr a great choice for building products, and I am always impressed by the breadth of industries adopting Zephyr for their solutions.
To give you a sense of how much work went into the release, it is always interesting to look at some numbers:
- Over 650 unique individuals contributed (new features, bug fixes, documentation, …) to the main GitHub repository of Zephyr for this release alone.
- Of these 650 contributors, over 35% (230 people) were first-time contributors. This is a 20% increase from 3.6, and an important indicator of the capacity of the project to still attract new users and contributors.
- With over 7370 commits since Zephyr 3.6 came out the door, it’s an average of 3 commits that were merged every hour!
Before diving into the highlights of this release together, I think it is worth briefly focusing on what is a Long Term Support release, and what this means for you if you are building, or considering building, products with Zephyr.
Leveraging Long-Term Support (LTS) for stable and secure product development
Like I previously mentioned, Zephyr typically gets released every 4 months. However, it shouldn’t be news to you that building a hardware product typically takes much longer than just 4 months. From one Zephyr release to the other, a lot of things can change. While it is mostly for the better—new features, more hardware being supported, better performance, improved security, etc.—APIs might change, or deprecated features you were still using might get removed, which may directly impact your downstream development.
To address this, the Zephyr community has been releasing Long Term Support (LTS) releases every 2.5 years. During that timeframe, any major bug or security vulnerability affecting the release will be fixed. This allows product makers to have confidence they can build their product on top of a stable foundation that will be maintained for a much longer time than a traditional release.
So, what’s new in Zephyr 3.7?
As with every release, a lot has happened over the last four months, I encourage you to check out the detailed release notes to get the full change log. If you’re mainly interested in the highlights and how to use some of the new features, keep reading… and watching 🙂
I’ve put together a video tour of Zephyr 3.7 which, along with the rest of this article, delves into some of the most notable features. I’m also sharing tips to help you be more productive in your daily work and get the most out of your favorite RTOS!
As you read through the article, clicking on the ▶️ symbol will directly take you to the section of the video that shows the feature in action.
You probably also want to mark our next Zephyr Tech Talk on your calendars as we will be having a special episode next Thursday, August 1st, where I will be joined by several contributors and maintainers to discuss the release and, more importantly, answer all the questions you may have about it!
Without further ado, let’s dive into Zephyr 3.7’s new and noteworthy, shall we?
▶️ New Hardware Model
Microcontrollers and embedded devices have been around since well before the Zephyr project was started, obviously. Over the years, even the cheapest embedded systems have become increasingly powerful, and complex. It is now pretty common to find SoCs that have multiple cores, sometimes even using heterogeneous architectures (Arm-Cortex + RISCV). This started to make it difficult (and borderline impossible) to properly manipulate these devices in Zephyr, and describe all the hardware capabilities of the boards built around these SoCs.
Starting with Zephyr 3.7, a new hardware model is being introduced to provide a better, future-proof, solution for dealing with these new hardware architectures. I encourage you to read the documentation to learn more about the changes and how they might impact you. I would also highly recommend you watch the Zephyr Tech Talk from a couple months back that dives into the topic as well.
A focus on developer experience
You’ve often seen me talk about and demonstrate some of the neat, often hidden, features that can make you more productive as a Zephyr developer. Well, guess what? Zephyr 3.7 is adding even more!
▶️ EDK
The LLEXT Extension Development Kit (EDK) is a new tool that makes it easier to develop LLEXT extensions for Zephyr.
As the name indicates, an “extension” complements your core application, and as such might very likely be written by a third-party. What’s more, it is also quite likely that these “extensions” will have little to do with Zephyr itself. For example, you may be building some kind of generic graphical user interface that you want your customers to be able to customize: while your core application is of course Zephyr-based, the “hooks” to extend its GUI are likely pretty generic. Similarly, if you’re looking at enabling dynamic loading of an AI model into your smart sensor, the API allowing for a model to be dynamically loaded is likely Zephyr agnostic as well.
The new EDK feature allows to easily package all that is needed by a developer to implement an extension, in an easy to consume way (essentially a ZIP file). An EDK package is effectively composed of all the headers that might be needed by the to-be-developed extension, but also contains basic CMake plumbing so that building the extension is also a breeze.
The LLEXT Extension Development Kit is extensively documented here and in the dedicated code sample but essentially, if you’ve been using LLEXT already, building the EDK package for your application is as simple as using the new llext-edk build target.
▶️ Power Management shell commands
The Zephyr shell is incredibly useful to interact with your device and troubleshoot issues without having to write any code. Power Management is a very important aspect of Zephyr and one of its key features. Whether you’re bringing up a new board, writing your own drivers, or simply writing an application, there are many reasons why you might want to “look under the hood” and see if the power management is doing the right thing.
Enabling the new Power Management shell (look for Kconfig option CONFIG_PM_DEVICE_SHELL) will enable several new shell commands to allow you to force a device to enter a specific power state, to easily visualize how many “users” there are for each device if you’re using runtime power management, and more.
▶️ Accessing the Zephyr console over Bluetooth
One thing I find truly amazing about Zephyr is how all the low-level services such as logging, tracing, or the shell, are designed to be fully agnostic of the transport layer. When it comes to the super handy shell, this means you can use it over a serial link, MQTT, Telnet, …
As Zephyr 3.7 introduced support for NUS (Nordic UART Service), it is now possible to have your Zephyr console exposed over over BLE as well. What’s even cooler about it is that enabling the feature can be done through a “snippet“, i.e. any Bluetooth-capable device is just a west build -S nus-console [...] away from giving you the ability to control it remotely over BLE.
▶️ Documenting how to use popular IDEs and code editors
Zephyr RTOS provides the foundation for a wide range of embedded applications. How one actually develops these applications is typically a matter of developer preference, and may also depend on the tooling provided by your silicon vendor. That being said, there is no reason why the Zephyr Project shouldn’t try to provide some basic guidelines whenever possible, hence why we now have two new documentation pages giving you some hints as to how to do the initial setup of your Zephyr developer environment for Visual Studio Code and CLion.
Security
Zephyr 2.7 LTS was released in October 2021, and it’s been the foundation for many commercial products. You might not know it, but the Zephyr Project is effectively equipped with its own Product Security Incident Response Team (PSIRT), something that is quite unique in the open-source RTOS world. The PSIRT is responsible for handling security vulnerabilities in Zephyr, and ensuring that the community is informed about them in a timely manner. To that effect, we encourage anyone building products with Zephyr to subscribe to our Vulnerability Alert Registry.
Since October 2021, the project has effectively addressed over 40 CVEs and a recent independent external security audit from NCCGroup only found two low severity issues in the kernel.
Adoption of TF-M PSA Crypto API
Until now, Zephyr has been lacking a unified API for cryptography. This was causing a lot of fragmentation in the codebase with more often than not, resources being wasted for a duplicate implementation of the same cryptographic algorithm would be pulled in from various places (TinyCrypt, Mbed TLS, …). This was also making it difficult to keep the attack surface under control, as more implementations means more potential vulnerabilities.
As of Zephyr 3.7, TinyCrypt is being phased out and PSA Crypto becomes Zephyr’s standard API for all things cryptography, and the code base has been updated accordingly.
SPDX 2.3 support
Zephyr has been supporting the automatic generation of Software Bill of Materials (SBOM) for a given application for a while now. This is a key feature for anyone building products with Zephyr, as it allows you to easily identify which software components are being pulled into your final product, and it’s becoming an increasingly important requirement for many industries (also, Cyber Resilience Act anyone?).
Starting with Zephyr 3.7, the SPDX tooling has been updated to support SPDX 2.3, which enables capturing more complete information about the software components being used. As SPDX 3 was recently released, it is likely that Zephyr will be updated to support it in the future.
▶️ PURL/CPE support
In the context of this LTS release, it is nice to see that the SPDX tooling in Zephyr now supports the inclusion of PURL or CPE identifiers in a Zephyr module’s metadata.
Effectively, this allows to associate with a Zephyr module the identifier used by public security databases such as the National Vulnerability Database (NVD). These identifiers are then properly captured in your SBOM for all the modules you are pulling into your application, which enables you to more accurately determine whether your application is affected by a known vulnerability. More importantly, it eliminates the cost associated with false positives, as you can now quickly determine whether a vulnerability reported in a given component corresponds to the actual version you’ve been shipping in your product.
▶️Sensors
A lot of work went into improving the Sensor subsystem to provide a new abstraction model that decouples reading sensor data from actually decoding it. This is particularly useful to enable scenarios where the raw sensor data can be decoded independently from its acquisition (think e.g. decoding on-demand on a different processor), or can be passed in “raw” form to a sensor fusion pipeline. In this new model, reading is by default asynchronous and leverages the Real-Time I/O subsystem to enable chaining asynchronous requests, or starting requests against many sensors simultaneously from a single call context.
Networking
▶️ New HTTP server library
This one is probably one of the most awaited features of Zephyr 3.7. A new HTTP/2 server library has been introduced, with support for both static and dynamic resources, as well as WebSockets. The library is designed to be easy to use, and is fully integrated with the Zephyr networking stack, which means that e.g. enabling HTTPS is pretty straightforward as it simply builds on top of the existing TLS support in Zephyr.
New end-to-end MQTT demonstrator
Given how rich Zephyr is when it comes to code samples—there are literally hundreds of them!—it may sound odd to put just one in the spotlight. However, I think it is really worth calling this one out for it is one of the very few samples that showcases more than one feature, driver, or subsystem, but rather a combination of several of them in order to demonstrate a complete end-to-end use case.
From showing you how to configure a DHCP client in your application, to establishing a secure connection to an MQTT server and publishing temperature data as JSON payloads, this sample really covers a lot of ground.
This sample is actually at the heart of the PTP demo in the video, so keep reading 🙂
▶️Support for Precision Time Protocol (PTP)
The Precision Time Protocol (PTP) is an IEEE standard (IEEE-1588) that is used to synchronize clocks in a network, typically a local area network.
When looking at Industrial IOT applications, PTP is critical to ensure that multiple devices capture real-time events at the same time. This is particularly useful in applications where multiple sensors need to be sampled at exactly the same time, or where multiple actuators need to simultaneously trigger.
Zephyr 3.7 introduces support for PTP which, granted your Ethernet network adapter supports hardware timestamping, enables you to synchronize the clock of your device within microseconds of a reference clock, or to effectively act as a reference clock for other devices on the network.
POSIX
POSIX support has been extended, with most Options of the IEEE 1003-2017 System Interfaces receiving support, as well as most Options and Option groups required for PSE51, PSE52, and PSE53.
Bluetooth
Bluetooth Host has been extended with support for the Nordic UART Service (NUS)—as already highlighted in the section about accessing the Zephyr shell over BLE—Hands-free Audio Gateway (AG), Advanced Audio Distribution Profile (A2DP), and Audio/Video Distribution Transport Protocol (AVDTP)
And more…
From the dozens of new boards and SoCs to the numerous new drivers introduced in this release, this blog post only scratches the surface of what Zephyr 3.7 has to offer. Again, please make sure to check out the full release notes as well as the accompanying migration guide that will help you with identifying some of the changes you might need to apply to your downstream project based on Zephyr 3.6.
Meet our release managers for Zephyr 3.7
The Zephyr 3.7 release is yet another milestone achieved through the collective efforts of an incredibly passionate and dedicated community. As always, our team of release managers has been instrumental in ensuring this release is, once again, going out exactly on the expected date.
Anas and Alberto both deserve a huge thank you for their hard work and, to conclude this blog post, I have asked them their take on this release:
