IoT Zephyr

Zephyr Weekly Update – NVMe support, and more!

Welcome back to the Zephyr Weekly Update series, covering the week of April 8-14, 2023. It is really great to see more and more of you are starting to follow and share these updates! As always, I’ve dug through last week’s commits and GitHub activity to bring you some noteworthy highlights.

This week I’m particularly excited about the addition of NVMe controller support as it is a nice demonstration of how Zephyr can address both very small/constrained scenarios, but also bring a compelling feature set to folks looking at more advanced scenarios based on more powerful MCU/MPUs.

NVMe support

NVMe (Non-Volatile Memory Express) is a high-performance storage protocol that’s designed specifically for NAND flash memory (think: Solid-State Drives (SSD), M.2 cards, …).

NVMe logo

Thanks to several contributions from Intel, Zephyr now supports the use of NVMe controllers and disks. What’s more, the disks are being exposed through Zephyr’s standard Disk Access API, and therefore can also be used through the File System API.

If you’re used to using the Devicetree to e.g. attach an SD Card controller to an SPI bus, it will look somewhat familiar when you’ll be attaching an NVMe disk to a PCI Express interface. For example:

#include <zephyr/dt-bindings/pcie/pcie.h>
/ {
    pcie0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "intel,pcie";

        nvme0: nvme0 {
            compatible = "nvme-controller";
            vendor-id = <VENDOR_ID>;
            device-id = <DEVICE_ID>;
            status = "okay";

All the commits related to adding NVMe support are linked in pull request #55643.

New boards supported & SoC updates

  • The PhyBOARD Pollux from PHYTEC is a development board featuring an i.MX 8M Plus Quad with 4×1.6 GHz cores, a neural network accelerator, and connectivity options such as Ethernet w/ TSN, RS-232, RS-485, … which make it a good option for implementing process visualization applications, quality control, etc. (e03884af and documentation page).
STM32 Nucleo-144 development board with STM32H563ZIT6 MCU
STM32 Nucleo-144 development board with STM32H563ZIT6 MCU
  • STMicroelectronics keeps working on adding support for their STM32H5 boards, this week it’s the Nucleo H563ZI (784d7321).
  • Power management support has been added for the Silicon Labs EFR32BG SoCs (c939d6a)


  • Really nice to see a new Ethernet controller driver for the popular LAN91C111 chip from SMSC/Microchip (28ff3e1d8c).
  • The TI ADS7052 is a high-speed, low-power, 14-bit ADC with 1Msps throughput (9fa35bc9a0).
  • The DS2482-800 from Analog Devices (Maxim) is a I²C to 1-Wire Bridge Device. It allows to talk to up to 8 1-Wire slaves from 1 I²C master. (691228ce01)
  • A generic NTC (Negative Temperature Coefficient) Thermistor sensor driver has been added (5d4352f).
    In order to make it more straightforward to convert raw resistance readings into actual temperature, a lookup table can be pre-generated using this script. Using the thermistor’s nominal resistance and its beta value (resistance value at 25°C / resistance value at 85°C), it spits out a lookup table in the form of a Devicetree node that the generic driver will then use to convert the measured resistance into an actual temperature.
    • You can check out the TDK RoboKit 1 board definition for an example of how the driver can be used/configured. See here for the thermistor sensor config, and here for its RT table.
  • The SmartBond DA1469x SoC from Dialog (now Renesas) is a BLE-capable Cortex-M33 based chip, and Renesas just contributed an I2C controller driver for it: (6cf3fe1d3f).
  • Support was added for the DDR memory controller on SiFive SoCs (71a6c22731)
  • The Microchip MCP970x thermistors are low-cost, low-power sensors for measuring temperature in the -40°C to +125°C range. Thanks to Nick Ward, there’s now a driver for it in Zephyr! (162c47ffc4)

Bluetooth Audio Enhancements

  • Several changes and refactoring around the Bluetooth LE Broadcast Audio functionality, in particular the implementation of the scan delegator. See PR #51679 for more details.

Noteworthy updates to existing drivers

  • The driver for the popular BMI270 IMU (Inertial Motion Unit) now supports ANY_MOTION and DATA_READY interrupts, making it possible to use the sensor in “trigger” mode vs. having to regularly poll data — quite convenient for actual motion detection, eh? (7d23e03)
  • NXP FlexCAN driver now supports CANFD variant (95b8bf3)
  • Updated Microchip MEC172x QMSPI-LDMA driver to work with Zephyr’s SPI NOR flash driver. (5c00a83)


  • The die_temp_polling samples will now work out-of-the-box for all STM32 boards (and there are dozens!), as their Devicetrees have been updated with the relevant alias (die-temp0) for exposing the CPU Die temperature sensor (fee0c82).
  • Support for Scan Delegator added to Broadcast Audio Sink sample (e00500a)
  • DHCPv4 sample now supports Arm FVP (Fixed Virtual Platform) (1ae558f5b4).
  • The new IVSHMEM Doorbell Sample Application shows how two processes on different operating systems can communicate using ivshmem (Inter-VM Shared Memory Communication).

Housekeeping / API changes

  • picolibc guru Keith Packard has proposed to change the main() return type from void to int in the entire code base. This better aligns with C and C++ standards. (see more details in PR #54628)
  • Removal of the need for a dummy device pointer in SYS_INIT functions (a5fd0d1).

As always please feel free to jump in with your thoughts or questions in the comments below, and we’ll talk next week!

Please also consider sharing the article in your professional network, as it makes a huge difference in getting these changes in front of the right people 🙂

If you enjoyed this article, don’t forget to subscribe to this blog to be notified of upcoming publications! And of course, you can also always find me on Twitter and Mastodon.

IoT Zephyr

Zephyr Weekly Update – Spring boards!

Welcome to the Zephyr Weekly Update series covering the week of March 31-April 7, 2023. By now I am hoping many of you know the drill: I look at last week’s commits and GitHub activity to extract some of the things that I think you will not want to miss!

I am really happy to see the addition of a driver for the NXP SC18IM704 (read on in the Drivers section below)—not that I care about this chip specifically, but it is demonstrating some very interesting Zephyr capabilities.

New boards supported

It’s frankly impressive to see how many new boards get added each week. See for yourself:

phyBOARD®-i.MX 8M Mini
phyBOARD®-i.MX 8M Mini
  • The phyBOARD Polis from PHYTEC is a very beefy board powered by an i.MX8MM chip (i.e. a quad-core Cortex-A53 @ 1.6 GHz + a Cortex-M4 running at 400 MHz). The carrier board is equipped with a variety of connectors and interfaces for e.g. CAN FD, WLAN, etc. (see 180f1ffb5c and documentation page).
  • The LoRa-STM32WL-DevKit from OLIMEX is a LoRa/LoRaWAN developer kit with an interesting form factor, and the ability to run out of a AA battery. (29e78deb67 added support for new revisions of the board — rev. C and rev. D).
  • Lunar Lake is Intel’s next generation of microprocessors. Support has been added upstream for the audio DSP (ADSP) that can be found in the accompanying Tensilica-powered chipset. (f5728c298d, e2881fe61a).


This week, as always, we have several new drivers joining the hundreds already available. I personally always learn a lot when skimming through those, and the first one below is a great example of what I mean by that!

  • The NXP SC18IM704 is a UART to I²C-Bus Bridge. I highly encourage you to check this driver out, even if you don’t care about this device in particular. It is a really great example of how powerful the Zephyr devicetree can be — the driver can be attached to an existing UART bus to expose nodes that effectively behave as an I2C controller (and GPIO too, since the SC18IM704 happens to have a couple). And as an application developer, you really won’t care about the “internal” UART-to-I²C ASCII-based protocol, you’ll just use the I²C API! (cd6fe580b0, 9b36e723f4).
  &uart0 {
    status = "okay";
    pinctrl-0 = <&uart0_default>;
    pinctrl-names = "default";
    sc18im704: sc18im704 {
      compatible = "nxp,sc18im704";
      status = "okay";
      target-speed = <115200>;
      reset-gpios = <&gpio1 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
      i2c_ext: sc18im704_i2c {
        compatible = "nxp,sc18im704-i2c";
        status = "okay";
        #address-cells = <1>;
        #size-cells = <0>;
      gpio_ext: sc18im704_gpio {
        compatible = "nxp,sc18im704-gpio";
        status = "okay";
        #gpio-cells = <2>;
        ngpios = <8>;
  • I am always excited to see more display drivers being added. Did I mention how much I love embedded GUIs? The Orise Tech OTM8009A LCD panel driver from Orise Tech can now be used with Zephyr (84fc689d48). You’ll find 4.63″, 800×480px, 65K colors LCD panels using this controller for just a couple of US dollars on AliExpress — hard to beat!
  • Last week a new driver for emulating UARTs. This week a new emulated RTC driver made its premiere (ae36da516a), and it can already be used on the native_posix target.
  • The SBS Gauge driver keeps getting improved to implement more features from the SBS (Smart Battery Sytem) specification. This week, support for the “AtRate” properties has been added (9727cafb41). The idea is to be able to ask the fuel-gauge IC the estimated time at which the battery may be full/empty based on a specific charge/discharge current (the rate).
  • A new rtc.h RTC (real-time clock) API header has been added to standardize communication with real-time clocks (b557a1d711). The definition of the handlers one may want to use from user space (to be notified when an alarm expires, for example) has also been added.
STMicroelectronics B-LCD40-DSI1 shield
  • MIPI-DSI host controller (as found in e.g., STM32H7 series) driver has been added (06c58fdcc2). The MIPI-DSI (Display Serial Interface) controller provides a way to interface with serial displays using a reduced number of pins.


Lastly, some interesting updates to samples:

As always please feel free to jump in with your thoughts or questions in the comments below… and see you next week! 🪁

If you enjoyed this article, don’t forget to subscribe to this blog to be notified of upcoming publications! And of course, you can also always find me on Twitter and Mastodon.

IoT Zephyr

Zephyr Weekly Update – Gotta love ’em snippets

Welcome to the second edition of the Zephyr Weekly Update series covering the week of March 24-31, 2023. In this series, I try to highlight some of the noteworthy changes that made it into Zephyr over the past week.

This week is all about snippets, a couple interesting new boards, and as always lots of activity on the drivers front. Let’s dive right in!


The most significant update this week is the introduction of Snippets.

If you’re like me, you’ve probably often found yourself reusing similar snippets of configuration (sometimes alongside corresponding devicetree overlays) to add a bit of functionality to your project. Things like overriding the default physical UART and Zephyr console to use a USB CDC-ACM UART one instead, enabling your favorite debugging combo (shell, custom log levels, …), etc.

However, the current build system lacked an extensible and composable solution that allows for capturing and naming such “snippets”, so that they can be referenced at build time, as opposed to copied repeatedly across your various projects.

Enter snippets! Snippets help streamline your project’s configuration by allowing you to define commonly used settings and then reference them when needed. This way, you can maintain a cleaner, more organized project structure while reducing the risk of errors caused by manual copy-pasting or inconsistent configurations across various parts of your project.

If it’s still not 100% clear to you how snippets can help you, check out this sample. It demonstrates how adding and enabling a USB CDC-ACM console to your project is now just a west build -S cdc-acm-console […] away. This will, behind the scenes, automagically:

  • add a cdc-acm-uart to an existing zephyr_udc0 node.
  • override the chosen zephyr,console so that it uses it.
  • set the proper KConfig options so that the USB device stack automatically boots up and is properly configured and will of course enable the new USB-based console.

Boards and SoC support

Arduino Giga R1 Wi-Fi
Arduino Giga R1 Wi-Fi

STM32H573I-DK Discovery kit
STM32H573I-DK Discovery kit
  • Support for the Arduino Giga board dropped shortly before I started this weekly update. It’s an impressive dual-core board from Arduino, which was recently announced and supported in Zephyr from day 1! As of this week, it is now also possible to use it for BLE [cf1ee6f615]
  • STMicroelectronics will soon be releasing a new Discovery Kit (STM32H573I-DK) for their STM32H573IIK3Q MCU.
    Commit [1f23bd7cf7] added support for this Arm Cortex-M33 based board featuring 2 MB of flash memory, and 640 KB of SRAM. It also has an LCD display and a Wi-Fi module, so it’s getting on my wish list!
    • In fact, it goes beyond just this specific board, as support for the complete STM32H5 series has been added [3b1dd7380b]
  • Added remote flashing support for MEC172xEVB_ASSY6906 board [efb3ccf2db]
  • Implemented cache management API for ARM Cortex-A and Cortex-R [98d4faf099]


Texas Instruments BP-BASSENSORSMKII BoosterPack™
Texas Instruments BP-BASSENSORSMKII BoosterPack™
  • The TMD2620 proximity sensor is the kind of sensor you could find in your phone for detecting when to turn the screen off due to it being close to your ear. Commit [924ac2265d] added support for it, including the integration with Zephyr’s Power Management system.
    • A code sample has also been added so you can easily try things out.
  • A new experimental driver is available for UART emulation [6180f96799].
  • The BP-BASSENSORSMKII Booster Pack from Texas Instruments is a feature-packed shield with tons of sensors (6-axis inertial sensor, 3-axis magnetometer, optical light sensor, temperature, humidity, …) that can be useful in building automation scenarios.
    Commit [524f01b60c] added support for it 🙂
  • Fabio from Google added an interesting new “longpress” input device that helps deal with making the difference between long-press and short-press events. Press a button for less than a configurable delay? That’s a short press! Otherwise, that’s a long press, and it will emit a different key event [5b36b4fa16]
  • Also related to input drivers, it’s now possible to use the newly added kscan input driver to listen for input events and report them on a kscan API. This allows porting kscan drivers to Zephyr’s input APIs while maintaining compatibility with the existing kscan-based applications. [a9735abf84]
  • Added flash readout and write protection support for STM32F4 [d652da5acb] [b6078cc906].
  • Added documentation for the Battery Charging 1.2 driver [24d5bac58f]
  • Added i2s domain clock support for STM32 devices [87f3e331a6]
  • New emulator for the PI3USB9201 USB charging detector [9b8c4ee847]
  • Added driver for Intel’s ADSP watchdog [ea405eb49e]
  • Several improvements around I3C [1f757bc67f] [2f02d6ca81] [62f22f8d3b].


  • Expanded AICS (Audio Input Control Service) API support to include audio [33bf1fa0c6]


You may be familiar with the Pmod standard interface that allows to easily attach peripherals to development boards. A new GPIO nexus has been added, allowing you to define your Pmod port as a node in your device tree [9d50b143ae]

I hope you find this update useful. Please share your thoughts in the comments and don’t hesitate to share the article widely to help spread the love for Zephyr! 🪁

If you enjoyed this article, don’t forget to subscribe to this blog to be notified of upcoming publications! And of course, you can also always find me on Twitter and Mastodon.