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.
Zephyr is not heavily promoted on the ST website, but it is listed in their embedded software solutions document.
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
westis 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
- 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.