We recently started looking at Zephyr for a STM32H7 based system. We have been using the ST32CubeIDE + FreeRTOS, a fairly obvious choice as it is built into the mainstream ST tools/IDE. Some notes on this stack:
easy to get started with a graphical tool to configure the chip
generate a lot of code, and again, easy to get started.
FreeRTOS integration is decent, but not tight with the STM32 SDK
Using third-party stacks like TinyUSB and LWIP are common, but the integration is not trivial.
the ST Cube generates a lot of XML which is not really human readable and difficult to store in Git if multiple people are making changes at the same time.
I have heard about Zephyr, so we recently decided to give it a try. In a day, one of the project engineers had Zephyr running on our custom hardware. In another couple of days, the Ethernet and HS USB were working.
Notes on Zephyr so far:
a tool command-line tool named west is used to set up a build, manage repos, flashing, etc.
It is a lot like Linux – everything is well integrated.
uses the KConfig build configuration system. This is nice as it allows very granular configuration of what is included in the build.
Device Tree is used to configure drivers. As some say, Zephyr porting to new hardware is 80% configuration, 20% code. It sometimes takes some work to figure out what config entries you need, but overall the process seems pretty nice. A declarative configuration like DTS forces a nice clean separation of code and configuration
Zephyr configuration is human-readable and very easy to store in Git, even with multiple developers making changes.
CMake/Ninja is used to build
ST Link automatically works for west flash
Zephyr HAL layers are in separate repos, but they are in the Zephyr github space and seem to follow very consistent guidelines (Issues are tracked in the main Zephyr repo, etc).
Zephyr provides a lot – ztest, zbus, etc.
The big difference I see between Zephyr and other solutions like FreeRTOS is that Zephyr takes responsibility for integrating the entire solution, instead of developing the core, washing their hands, and handing it off to chip vendors/users to do the integration. If a Chip vendor wants to play in the Zephyr space, then their hal layer is provided in the Zephyr github space and there is support in the main Zephyr west.yml for it.
As MCUs get more complex, it seems like something like Zephyr is needed to tame this complexity.
Zephyr has a really nice shell – tab completion works nicely. Most subsystems (network, i2c, etc) have shell config options. Additionally, most driver subsystems have debug levels so you can turn up the debugging levels just on that subsystem if there are problems.
this is powerful and more modern. I wonder if it can build with clang as compiler as well if it can then we have an inherent cross compiler on system and can simplify toolchain requirements.
I’ve been curious about the west build tool used in Zephyr. This page has the rationale for creating the tool and compares it to Git submodules and Repo:
Comparison of development activity of various RTOS projects. It appears that Zephyr has one to two orders of magnitude more development activity than other projects. Part of the difference is likely that Zephyr is more than just a kernel and includes many drivers for i2c/SPI chips, MCUs peripherals, etc. Traditionally, MCU vendors would likely do some of this driver work internally and then package it with a RTOS kernel. The Zephyr model is completely different.
Note, these metrics are not perfect and likely don’t reflect everything that is going on, but give us some idea.
I’ve been wondering how easy it will be to maintain old Zephyr projects – will current versions of West work with old versions of Zephyr? It is supposed to work:
