ST is thrilled to announce that the just-released Zephyr 4.4.0 is adding support for the STM32C5, STM32H5E/F, STM32U3C5, as well as the X-NUCLEO-IKS5A1 daughter board, the EVKITST87M01-1 evaluation kit, and the ST B-DSI-MB1314 touch-sensitive display, among many other things, such as sensors and modems (ST87M01). It’s a testament to the collaboration between ST and the Zephyr community. Over the years, we have mainlined drivers, optimized performance and supported new features. And while we do have partners who use Zephyr and benefit from these contributions, this also stems from our desire to work with open-source projects that help democratize real-time operating systems and lower the barrier to entry.
How it started?
The privileged position of the ST software ecosystem
Avid readers of the ST Blog are quite familiar with the STM32Cube Ecosystem and the other ST software that grant developers low-level access to our devices, such as MEMS Studio, which makes machine learning on sensors even more approachable. For many, tools like STM32CubeProgrammer help make our hardware more accessible, while ST’s software packages for its microcontrollers, microprocessors, sensors, and more provide drivers, middleware, example code, and more. Recently, utilities like NanoEdge AI Studio also helped embedded software engineers work on neural networks and optimize their AI applications at the edge, thanks to features like synthetic data generation. Put simply, we strive to always serve more users and make the latest trends more within reach.
The need for projects like Zephyr
Yet we know that some of our customers require projects like Zephyr, which is why we have worked closely with them since the beginning. For instance, some companies deal with a wide range of competing devices and, therefore, need a more agnostic system. It also helps bring a general abstraction layer for complex technologies like wireless connectivity. Instead of adopting a vendor-specific approach, Zephyr can help make projects more portable and interoperable. Others may want to develop a proprietary subsystem and, consequently, choose Zephyr at the start of the project and build on it over time. Finally, some simply gravitate toward open-source projects.
The importance of the collaboration between ST and Zephyr
It’s to help meet these customers’ needs that ST contributes to the Zephyr project and supports its low-level APIs. Concretely, it means we work with Zephyr to support numerous peripherals and interfaces, including USB modules, LCD-TFT display controllers, networking interfaces, and much more. Since the beginning of the Zephyr project, ST engineers have contributed to the Zephyr codebase and the support community. In certain instances, we even help with critical technologies, such as low-power modes, recognizing that our contribution will benefit more than just the engineers using our products.
Another aspect of ST’s work on the Zephyr project is the significant effort involved in reviewing community contributions to the STM32 codebase. It may include new board support, bug fixes, and even complete drivers pushed and maintained by external contributors. Over time, these contributions have been responsible for a significant part of the STM32’s current status. Put simply, this is the other side of the collaboration on a project like this. Not only do we offer code, but we also bring our expertise to promptly validate and support those who contribute to our platform.
How it’s going?
New MCU support
Zephyr 4.4.0 is a good example of our dedication to the project. Just like our frequent updates to STM32CubeProgrammer bring new STM32 MCU support, this new version of Zephyr adds support for the STM32C5, STM32H5E/F, the STM32U3C5, and the STM32WBA2X. In some instances, like the STM32C5, this version adds support for DMA, I2C, SPI, ADC, timers, and watchdog. Since we just launched the STM32C5, Zephyr 4.4.0 is an inaugural release for the new series. For other devices in an existing series, the MCU support builds on what is already in place, enabling developers to leverage new part numbers.
New middleware features
Beyond the device itself, ST also brings updates to its drivers or middleware. For instance, among many improvements, v4.4.0 brings performance enhancements on STM32, adds RTIO and optimizes DMA in SPI STM32 drivers, and adds a stream API for ADC STM32 drivers. We also added the ability to inject ADC channels to enable immediate execution, overriding the regular sequence. Similarly, Zephyr 4.4.0 adds a portable API to read the one-time programmable non-volatile memory on STM32 MCUs. Usually, that means an ADC sensor can now access calibration data. We are also starting to make our I3C interfaces available on our STM32MP2 MPU, and we have moved our USB default stack to a newer and more robust version.
How to get started?
The best way to get started is to grab one of the supported ST board or shield and follow the Getting Started Guide. Once developers have installed dependencies, they simply get the Zephyr SDK and build the Blinky light sample program onto their board. The open source project even provides a dedicated page for each ST board. Hence, if one is using the STM32MP257F-EV1 Evaluation Board, the document gives out the exact command line to build Blinky for that particular system and the steps to start debugging. Zephyr also has a dedicated #STM32 channel on their Discord server.