Zephyr notes

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 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.

zephyr build system generates build/compile_commands.json, which is used by the clangd language server. Seems to be working in neovim.

There are also .editorconfig and .clang-format files in the repo – well done!

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:

https://docs.zephyrproject.org/latest/develop/west/why.html

Overall, I’m a little skeptical of inventing new tools to do superproject management, but in this case, it seems to make sense.

1 Like