Skip to main content

Zephyr Weekly Update – New Hardware Model

By March 8, 2024No Comments

Howdy! Before diving into this week’s news, I would like to extend an invitation to all of you reading this weekly update to consider submitting a talk for an upcoming Zephyr Tech Talk. As you have probably noticed if you watched previous episodes, these are very informal sessions, so you shouldn’t worry about having to prepare super polished slides (but cool demos are definitely a nice to have!).

If you are a maintainer of a Zephyr area you feel deserves more attention, or simply a Zephyr contributor or enthusiast eager to share insights about a topic you’re passionate about, please propose your idea here!

New Hardware Model

As announced in previous weeks, a new hardware model has been introduced for making it easier to support hardware configurations that were becoming difficult or impossible to describe with the legacy model.

This new model allows to better address multi-core (and sometimes multi-archictecture, too!) SoCs, as well as boards with multiple SoCs.

All the hundreds of boards supported in Zephyr have already been migrated, and what you need to do to migrate your own existing board definitions that you may be maintaining out-of-tree is descibred in the Board porting guide.

We will be having a Zephyr Tech Talk on the topic in just a few weeks, so stay tuned for that!

LED matrices as regular display controllers

I am sure some of you may have a love & hate relationship with Devicetree. It certainly takes some time to get used to the syntax and the sometimes opaque error messages in case of misconfiguration, but it is a super powerful and versatile tool.

This week, a new driver was introduced that I believe really illustrates quite well how one can really decouple their application code from the underlying hardware.

Zephyr already has a generic driver class for LED strips. You will find several drivers in the Zephyr tree (ex. for the popular WS2812 RGB LEDs) that implement the LED strip API and allow to set the colors of all the LEDs in the strip. As you can imagine, on the Devicetree side of things, the configuration of the driver includes things like how many LEDs are in the strip, or which pins/bus should be used to control the strip.

There is also a driver class for all things display controllers. Here, we’re talking about drivers exposing properties for configuring the resolution of the display, which pins to use to transmit pixel data, etc. In most cases, the application developer couldn’t care less about the specifics of the display controller, and they only use the display driver API to effectively put pixels on the screen. In fact, there’s even higher levels of abstraction, like the pre-integration with LVGL, which you’ve heard me talk about many times.

OK, so can you guess where I am going with this? Yep, a new driver now sits kind of in the middle of these two classes of drivers. It’s a display controller driver for LED matrices. Give it a phandle to an led-strip node, and you have your new display ready to rock & roll!

chosen {
    zephyr,display = &led_strip_matrix;
led_strip_matrix: led_strip_matrix {
    compatible = "led-strip-matrix";
    status = "okay";
    led-strips = <&led_strip>;
    chain-lengths = <256>;
    width = <16>;
    height = <16>;

(PR #68614)

Boards & SoCs

  • New MIPI DBI host controller driver for Renesas Smartbond. (PR #68426)
  • New WWDT watchdog driver for Nuvoton Numaker. (PR #68044)
  • New RTC driver for Raspberry Pi RP2040. (PR #64939)
  • nRF54 SoCs have two IP blocks that help with inter-domain signaling and IPC scenarios, namely VEVIF (VPR Event Interface) and BELLBOARD. These two peripherals now have drivers in-tree. (PR #69303).
  • Added support for Renesas Smartbond LCD controller (LCDC) display controller driver. (PR #67649)
  • If you are a user of the M5Stack Core2, you may have noticed that by default, the Grove connectors are not powered. Thanks to PR #67280 you can now control whether the Grove connectors should be powered or not using the bus_5v regulator.

General drivers

  • New cellular model driver for the Nordic nRF91 series. (PR #68981)
  • New flash driver for MRAM (Magnetic Random Access Memory) as found on the new nRF54H20. (PR #69800)
  • You may already be familiar with the regulator-boot-on Devicetree property which allows to ensures a given regulator is enabled when your application start. The new regulator-boot-off property now allows to do the opposite. (PR #69319)
  • New input driver for the Pixart PMW3610DM, a low-power laser mouse sensor. (PR #69722)
  • In the context of #69303, some work has also been done on cleaning up the mbox API (PR #69390)
  • #68776 i2c: RTIO context and some small drivers +1119 -140 (@teburd)


  • Support has been added for using QEMU on Windows in Twister. (PR #67595)
  • It’s now possible to set multiple IPv4 netmasks per network interface. (PR #68419)
  • Significant improvements were made to the State Machine Framework (SMF) to better support hierarchical state machines. (PR #66753)
  • LVGL exposes an API for rounding the coordinates of areas to redraw, as this can be needed for some display controllers. The new CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH and LV_Z_AREA_Y_ALIGNMENT_WIDTH KConfig options allow to make use of the rounding mechanism when needed. (PR #69410)
  • DTLS sockets now allow to send multiple fragments in the same sendmsg(). (PR #69280)
  • Breaking API change for CAN controllers as part of a rework of the manual bus-off recover. (PR #69460)
  • New POSIX APIs:
    • Support for getting and setting POSIX environment variables has been introduced (environ, getenv(), setenv(), and unsetenv()). (PR #66762)

A big thank you to the 12 individuals who had their first pull request accepted this week, 💙 🙌: @Dermiste, @jthm-ot, @zhaynxp, @jonathonpenix, @cradzik, @ajf58, @Deedone, @pfarwsi, @ChangNice, @glenn-andrews, @sibertdeclercq, and @gangli02.

As always, I very much welcome your thoughts and feedback in the comments below!

Benjamin Cabé