Also, we have two upcoming Zephyr Tech Talks after a few quiet weeks, make sure to RSVP to the events so that you don’t miss the opportunity to ask your questions live (and please help spread the word by relaying to your social network, if you feel like it!).

Introducing support for Renesas RX

The Renesas RX family is a line of 32-bit microcontrollers from Renesas Electronics which is positioned as an alternative to Arm Cortex-M.

I personally have no first-hand experience with this architecture, but it seems to be pretty competitive with regards to pure performance, as well as power efficiency. Renesas RX MCUs are a pretty popular choice in applications such as industrial automation, motor control, and healthcare.

It’s not often that Zephyr adds support for a new processor architecture, so let’s celebrate! Also worth noting that the Zephyr SDK 0.17.1, which was just released, provides RX toolchains which you can use to easily build your first apps for the QEMU board or the Renesas Starter Kit for RX130.

Video updates

Zephyr has been shipping with video support for a long time, but over the last year or so, this area has regained interest from various parties and has been incredibly active.

• A new Video Control Framework (PR #82158) is available, providing a standardized way to manage video device parameters.
• A Video Shell (PR #88566) was added, offering command-line utilities for interacting with video devices.
• Added support for many more Bayer, RGB, and YUV pixel formats (PR #88817).
• Common CCI (Camera Control Interface) utilities (PR #87935).

Simplifying downstream patch management with west patch

The west patch command is not new, but it’s only recently that documentation for it was added, so I thought it was worth mentioning.

This command allows you to organize and apply patches to Zephyr or Zephyr modules in a controlled manner, by means of a patches.yml file that stores metadata about the various patches. It allows, for example, to indicate whether a given patch corresponds to an open pull request.

patches:
  - path: zephyr/my-zephyr-change.patch
    sha256sum: c676cd376a4d19dc95ac4e44e179c253853d422b758688a583bb55c3c9137035
    module: zephyr
    author: Obi-Wan Kenobi
    email: obiwan@jedi.org
    date: 2025-05-04
    upstreamable: false
    comments: |
      An application-specific change we need for Zephyr.
  - path: bootloader/mcuboot/my-tweak-for-mcuboot.patch
    sha256sum: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    module: mcuboot
    author: Darth Sidious
    email: sidious@sith.org
    date: 2025-05-04
    merge-pr: https://github.com/zephyrproject-rtos/zephyr/pull/<pr-number>
    issue: https://github.com/zephyrproject-rtos/zephyr/issues/<issue-number>
    merge-status: true
    merge-commit: 1234567890abcdef1234567890abcdef12345678
    merge-date: 2025-05-06
    apply-command: git apply
    comments: |
      A change to mcuboot that has been merged already. We can remove this
      patch when we are ready to upgrade to the next Zephyr release.

New boards and SoCs

Some of the other boards and SoCs that caught my attention. As a reminder, there’s a new board being added to Zephyr almost every day, so the list below is not exhaustive!

• Initial support for the Cortex-R52 based Versal Gen 2 SoC RPU (Real-time Processing Unit) (PR #88667).
• ESP32-S3-Matrix (PR #84634).
• Ezurio BL54L10/L15/L15u DVK (PR #87525).
• STM32U5G9J-DK1 (PR #88550) and DK2 (PR #88787).
• Texas Instruments MSPM0 SoC series and MSPM0G3507 Launchpad board (PR #88725).
• Teensy Micromod (PR #88502).
• Several new WCH—remember? I already mentioned these crazy cheap RISC-V MCUs a while back—boards and correspoiding SoCs:
  • CH32V203 SoC and WeactStudio CH32V203 Blue Pill plus (PR #87490).
  • CH32V00x series and CH32V006EVT (PR#89361).

Drivers

• New sensor drivers:
  • PAJ7620 gesture sensor (PR #85351),
  • PZEM004T AC energy monitor (PR#89123),
  • WSEN-ITDS accelerometer (PR#86213),
  • RM3100 magnetometer (PR#89058).
• Numerous new display controller drivers were introduced, including SH1122 (PR #87431), SSD1320 (PR #87169), SSD1331 (PR#88178), SSD1351 (PR #89566), and ST75256 (PR #87584), all by @VynDragon
• Auxiliary Display: Driver for common 7-segment displays (PR #68501), and LCD1602 (PR #89654).
• New UART bridge driver (PR #89110) allows to configure bridge between two serial devices, for example a USB CDC-ACM serial port and a hardware UART.

uart-bridge {
         compatible = "zephyr,uart-bridge";
         peers = <&cdc_acm_uart0 &uart1>;
};

• Support for ADI TMC51xx stepper motor controller (PR #88350)
• USB Device Controller for Atmel SAM0 (PR #86814).
• AIROC Wi-Fi driver supports new devices and modules (PR #86137).

Miscellaneous

• It can sometimes be hard to keep track of all the files (.dts, .dtsi, overlays…) that make up your device’s Devicetree. The zephyr.dts file that’s generated as part of the Zephyr build now includes comments that indicate where each given node or property was last touched. It makes it much easier to find that damn overlay that keeps having the last word

/ {
	#address-cells = < 0x1 >;          /* in zephyr/dts/common/skeleton.dtsi:10 */
	#size-cells = < 0x1 >;             /* in zephyr/dts/common/skeleton.dtsi:11 */
	model = "Wio Terminal";            /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:15 */
	compatible = "seeed,wio-terminal"; /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:16 */

	/* node '/chosen' defined in zephyr/dts/common/skeleton.dtsi:12 */
	chosen {
		zephyr,flash-controller = &nvmctrl;       /* in zephyr/dts/arm/atmel/samd5x.dtsi:52 */
		zephyr,entropy = &trng;                   /* in zephyr/dts/arm/atmel/samd5x.dtsi:51 */
		zephyr,sram = &sram0;                     /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:19 */
		zephyr,flash = &flash0;                   /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:20 */
		zephyr,code-partition = &code_partition;  /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:21 */
		zephyr,display = &ili9341;                /* in zephyr/boards/seeed/wio_terminal/wio_terminal.dts:22 */
		zephyr,console = &board_cdc_acm_uart;     /* in zephyr/boards/common/usb/cdc_acm_serial.dtsi:9 */
		zephyr,shell-uart = &board_cdc_acm_uart;  /* in zephyr/boards/common/usb/cdc_acm_serial.dtsi:10 */
		zephyr,uart-mcumgr = &board_cdc_acm_uart; /* in zephyr/boards/common/usb/cdc_acm_serial.dtsi:11 */
		zephyr,bt-mon-uart = &board_cdc_acm_uart; /* in zephyr/boards/common/usb/cdc_acm_serial.dtsi:12 */
		zephyr,bt-c2h-uart = &board_cdc_acm_uart; /* in zephyr/boards/common/usb/cdc_acm_serial.dtsi:13 */
	};

...

• The board catalog now also includes shields as part of the listing. There are currently 150+ shields supported in Zephyr so it’s nice that it will now be easier to search for them more efficiently.

• CoAP Secure (CoAPS) support has been added, allowing to use DTLS to secure CoAP communication. (PR #65963).
• LLEXT now has basic support for x86 architecture (PR #90176) as well as ARC MPU (PR#89118).
• LVGL now supports multiple displays. (PR #86815).

• Support for Altera NIOS-II architecture has been dropped. (PR #89762)
• Added XSI_SINGLE_PROCESS and POSIX_CLOCK_SELECTION POSIX option groups (PR #89068).
• Optimizations to the ZMS backend for Settings (PR #87792).
• Added runtime Zbus observers pool (PR #88834) for dynamic observer registration.
• west now offers basic PowerShell auto-completion. (PR #88358)

A big thank you to the 73 () individuals who had their first pull request accepted since my last post, : @herculanodavi, @ZhaoQiang-b45475, @abhinavnxp, @batkay, @fiveohhh, @gudipudiramanakumar, @mefromac, @segerlund, @alexapostolu, @dsseng, @sayooj-atmosic, @edt-alex, @alrodlim, @Ole2mail, @cfunes-pragma, @cdrask, @wjklimek1, @squiniou, @Kronosblaster, @morishitaandre, @dependabot[bot], @PaulSchaetzle, @zbas, @sandro97git, @tobiwan88, @jsbatch, @gcopoix, @TomasBarakNXP, @mikolaj-klikowicz, @AnElderlyFox, @cbrake, @shiftee, @yolaval, @FKainka, @benson0715, @ct-lt, @Brandon-Hurst, @hdou, @jeremydick, @bastienjauny, @iwasz, @duerrfk, @ebmmy, @araneusdiadema, @srishtik2310, @jbr7rr, @mihnen, @muahmed-silabs, @leonmariotto, @conweek, @fmoessbauer, @AmaanSingh, @Harry-Martin, @ymleung314, @smfebe, @dantti, @meijemac, @thsieh97, @Vijayakannan, @vytvir, @kylebonnici, @tsi-chung, @yongxu-wang15, @anujdeshpande, @Lorl0rd, @minumn, @120MF, @cmm1981, @nordic-mik7, @dylanHsieh4963, @harristomy, @hfruchet-st, and @vignesh-aerlync.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Before diving into some of the highlights, I would encourage you to add the video recordings of the recent Zephyr Meetup Grenoble to your watchlist as there were quite a few interesting topics covered!

Network Packet Filtering Updates

It’s no secret that Zephyr’s networking stack is one of its great strengths. This week, some neat improvements to packet filtering have been introduced (PR #88544), including support for VLAN, statistics collection for number of packets affected by filters, a shell module, and more.

A new code sample is available and a great showcase for how you can leverage the Network Packet Filtering API (including the aforementioned improvements) to setup some filtering rules for e.g. implementing firewall functionality, network traffic control, etc.

For example, installing a filtering rule dropping any incoming packet larger than 200 bytes is as simple as:

static NPF_SIZE_MAX(maxsize_200, 200);
static NPF_ETH_TYPE_MATCH(ip_packet, NET_ETH_PTYPE_IP);

static NPF_RULE(small_ip_pkt, NET_OK, ip_packet, maxsize_200);

void install_my_filter(void)
{
    npf_insert_recv_rule(&npf_default_drop);
    npf_insert_recv_rule(&small_ip_pkt);
}

The code sample actually creates multiple VLAN networks, giving an opportunity to showcase rules that only apply to some interfaces. The net filter shell command also conveniently shows you a snapshot of which rules are in place.

uart:~$ net filter
Rule  Type        Verdict  Tests
[ 1]  recv        OK       3    eth vlan type[0x0800],size max[200],iface[2]
[ 2]  recv        OK       3    eth vlan type[0x0800],size min[100],iface[3]
[ 3]  recv        OK       1    iface[1]
[ 4]  recv        OK       2    eth vlan type[0x0806],iface[2]
[ 5]  recv        OK       2    eth vlan type[0x0806],iface[3]
[ 6]  recv        DROP     0

New UUID library

Generating and managing unique identifiers is crucial in many applications, and can be really useful to e.g. tag sensor data samples, generate session identifiers, etc. Thanks to @sorru94‘s work in PR #77884, Zephyr now includes a Universally Unique Identifier (UUID) utility library implemeting RFC 4122.

It provides functions for generating UUIDs (both v4 -random- and v5 -deterministic-), comparing them, and converting UUIDs between string and binary representations.

Check out the dedicated code sample for some code snippets.

New boards and SoCs

• Renesas RZ/G2LC SMARC EVK: Initial support Renesas RZ/G2LC SoC was added, alongside associated evaluation kit. The RZ/G2LC microprocessor is a dual Cortex®-A55 (1.2GHz) CPU.  (PR #88569).
• STM32 NUCLEO-WBA65RI: STM32WBA6 SoC is now supported, and the NUCLEO-WBA65RI is a great starting point to experiment with this ultra-low-power board (PR #88407).
• NXP FRDM-MCXA153: Added support for the NXP MCXA153 MCU and the corresponding FRDM board (PR #85644).
• BeagleBoard PocketBeagle 2 M4: The Cortex-M4F co-processor of the TI AM6232-based PocketBeagle 2 is now supported. (PR #87997).
• TF-M on Nordic nRF54L10: Initial support for TF-M now available on the nRF54L10 (PR #88442).

Drivers

• X-Powers AXP2101 Charger: The charger peripheral within this popular PMIC is now supported. The TTGO T-Watch S3 directly benefits from this since it’s one of the boards supported in Zephyr that uses an AXP2101 PMIC. Note to self: order one ASAP as it is a really cool looking device and now has even more peripherals supported 🙂 (PR #88125).
• I2C Controller driver added for the WCH CH32V RISC-V family (PR #87922).
• ITE IT51xxx Watchdog timer driver for ITE EC chips (PR #88470).
• Silicon Labs SiWx91x WiFi module now supports Background Scanning and Roaming (PR #87037).
• TI SimpleLink CC23x0 SPI controller support added (PR #84521).
• RTS5912 Tachometer Sensor driver (PR #86913).
• STM32N6 USB/UDC: Support added for the USB peripheral and device controller on the STM32N6 series (PR #84976).

Miscellaneous

• flash_area_copy() API: A new helper function, flash_area_copy(), was added to the flash map API, simplifying the process of copying data between partitions (e.g., for firmware updates) (PR #84604).
• Xtensa Userspace & Syscall Improvements: Numerous fixes and enhancements were merged for userspace support and system call handling on the Xtensa architecture (PR #88531).
• LoRaWAN Link Check: Support for the standard LinkCheckReq/LinkCheckAns MAC commands has been added to the LoRaWAN subsystem (PR #87828).
• Kernel Constructor Handling: Internal handling of C++ constructors (.ctors) and .init_array has been unified and simplified (PR #74700).
• New CRC Algorithm: Support for the CRC-32K/4.2 algorithm was added (PR #81558).

A big thank you to the 4 individuals who had their first pull request accepted this week, 💙 🙌: @tiennguyenzg, @apni2, @tpambor, and @dhanquna.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

New CI servers are blazing fast

There are literally hundreds of pull requests being submitted to Zephyr every week. We’re trying our best to have them go through a set of relevant tests on our continuous integration servers so that the proposed changes are effectively working, not causing regressions, etc.

With the sheer amount of pull requests involved, our servers are usually VERY busy, pretty much 24/7. Our infrastructure guru Stephanos recently completed the move to Hetzner as our new provider, and we now have a farm of very beefy AMD EPYC Genoa 9454P (48 cores / 96 threads!) powered servers that is significantly speeding up the times it takes for pull requests to go through CI (from several hours before to just about 20 minutes now, in most cases).

Interestingly, GitHub just announced this week that they’re making 96 vCPU runners generally available. Priced at $0.384 per minute (!) of usage, it’s a good reminder that Zephyr’s shared development model, with financial support from its member companies, brings a lot of “free” benefits to the community at large.

Twister harness for power measurement

Testing and validating power consumption of embedded systems is often a very manual and time-consuming task.

A new power harness was recently added to Twister, enabling automated power measurement and validation during test runs. As a reminder, a Twister harness is basically responsible for determining whether a given test passes or not. For example, one would often use the console harness to validate console output against e.g. a regular expression to confirm an application is working as expected.

With the new power harness, it is possible to use an external power monitor (the initial implementation supports the STMicroelectronics X-NUCLEO-LPM01A expansion board running PowerShield) to measure the current drawn by the device under test, and to express some “rules” as to what’s considered success or failure (ex. to ensure the peak consumption never goes above a given value).

The pull request that introduced this new feature (#85130) is probably the best starting point at this stage for you to get a closer look at how this works (and it looks like documentation for it is maybe a bit lacking at the moment, unfortunately). I haven’t spent a lot of time digging into this new feature just yet but I would be really curious to see people start extending it to support other popular power monitors such as Nordic’s PPK2, JouleScope, etc.

Bluetooth Hands-Free Profile (HFP) improvements

PR #77694 has recently been merged and it brings a pretty significant update to the already supported Bluetooth Hands-Free Profile (HFP) and adds support for features such as remote volume control, caller ID, memory dialing, and more (it’s over 11,000 lines of code that were added!).

New boards and SoCs

As always, way too many boards added so I am focusing on just a few

• STMicroelectronics STM32MP13 micro-processor is based on Arm Cortex-A7, and a lot of work went into not only adding support for it in Zephyr—PR #87687—but basically also introducing Zephyr support for Cortex-A7 in the first place!
  Should you want to get started with Cortex-A7 on Zephyr, I guess you best bet for now is to then use the STM32MP135 Discovery kit port which, quite naturally, was also introduced in the same PR
• You may or may not know that Zephyr is widely used to write Embedded Controller firmwares. For example, laptops such as Chromebooks or Framework Laptops are effectively leveraging Zephyr for all kinds of low-level hardware management stuff (power management, keyboard interfacing, etc.).
  PR #87095 introduces support for ITE Tech’s IT51XXX SoC series. IT51XXX is a 32-bit RISC-V microcontroller with 128KB SRAM, 512K-1M of embedded flash, and a variety of buses and peripherals you’d expect to find on a computer motherboard (SMBus, I3C, cryptographic engine, …)
• Two new XIAO boards from Seeed Studio: XIAO RA4M1 and XIAO MG24.

Drivers

• A new MBOX driver for Arm MHUv3 (arm,mhuv3) has been introduced. The MHU (Message Handling Unit) is a standard hardware block found in many multi-core Arm MCUs. It is designed to facilitate low-latency signaling and message passing between different cores. (PR #82564)
  You can read more on Arm MHU here.
• New sensor drivers added for:
  • TDK ICP201XX pressure sensor (PR #83914),
  • Liteon LTR329 ambient light sensor (PR #85453),
  • ESP32-C6 internal temperature sensor (PR #87175),
  • TI DAC161S997 DAC (PR#86285),
  • NXP PCF2123 RTC (PR #88049),
  • PAT9136 Optical Flow Sensor (PR #86747)
• New driver for the Sitronix ST7701 display controller (PR#85569).
• New Espressif LP UART driver targetting the Low Power core found on Espressif SoCs such as ESP32-C6 (PR #87684)
• New driver for the TI BQ25713 battery charger IC (PR #86791).
• The Silicon Labs EUSART driver now supports Power Management, Asynchronous API, and DMA (PR #85796).
• I2S support was added for Espressif ESP32 and ESP32-S2 (PR #83710).
• The Bosch BMA4xx accelerometer driver now supports streaming API (PR #83575).

Miscellaneous

• Arduino GIGA Display Shield: Support for the display shield designed for the Arduino GIGA R1 board has been added (PR #85569).

• Coredump In-Memory Backend: The coredump subsystem now features an optional in-memory backend, useful for capturing crash information on systems without persistent storage (PR #87565).
  See CONFIG_DEBUG_COREDUMP_BACKEND_IN_MEMORY.
• Some long overdue improvements to Zephyr’s JSON library, with better support for parsing/serializing “NaN”, “Infinity”, scientific notation, and char arrays. (PR #86956 & #87580)
• It’s know possible to suspend/resume the task watchdog, which can be useful when the system needs to go into a suspend state. (PR #87590)

A big thank you to the 41 individuals who had their first pull request accepted this week, : @peterwangsz, @juickar, @seankyer, @raulgotor, @dereje-demant, @Bucknalla, @PicoBoy2017, @aisuneko, @stefan-golinschi, @KwsBaer, @thanhthe23, @pir0n, @manoj-aerlync, @fimohame, @marekmaskarinec, @Yunshao-Chiang, @tq-delimayuki, @Pharb, @kesyog, @AdamOpenshaw, @vbrzeski, @woobacca, @saimohith-google, @lukkelele, @darrenlu-ambiq, @PeggyCienet, @DavidCerrone, @ivanwagner, @derekvalleroy, @caiohbm, @jamesturton, @rob-robinson-14, @cjwinklhofer, @ajordanr-google, @echistyakov, @bukepo, @cichiwskyj, @Tim-Wang38, @Gibson431, @paultimke, and @robertperkel.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Before diving deeper, don’t forget our upcoming Zephyr Tech Talk next Wednesday, April 2, where David Brown will tell us all there is to know about Rust on Zephyr — what’s there already, what’s coming, and how you can help!

And now for your weekly-ish updates

Introducing MQTT 5.0 support

We’re getting dangerously close to reaching 90,000 issues/pull requests in the project’s GitHub repository, so it’s not often that an issue in the 20,000 range is being closed This week, we just added support for MQTT 5.0 (the project has of course supported MQTT 3.1 for quite a while), which was tracked in issue #21633 open on Jan. 1, 2020!

MQTT 5.0 introduces several improvements over MQTT 3.1(.1), such as the addition of user properties and metadata fields in the CONNECT, PUBLISH, and SUBSCRIBE packets. It also features better error reporting, with reason codes offering clearer feedback when things go wrong.

The addition of MQTT 5.0 support should mostly be transparent for existing MQTT 3.1.1 users

New boards and SoCs

Some (only a few, really) of the new boards you will probably interested in hearing they are now supported in Zephyr:

• Adafruit ESP32S2 and ESP32S3 Feather boards
• WizNet W5500 EVB Pico2 (PR #84834) and Pimoroni Pico Plus2 (PR #77859) are two new options available to you if you want to play with RP2350-based boards.
• Support for ADC, PWM, I2C, SPI, and TRNG has been added to Arduino UNO R4. (PR #85824)
• … and many new boards and SoCs added by Renesas, STMicroelectronics, Silicon Labs, TI, and others.

Drivers

• Add support for AXP2101 power management IC, which is mostly replacing the AXP192 and is used in several popular devkits from M5Stack and others. (PR #82474)
• New driver for Bosch BMM350, a 16-bit high accuracy/low-noise magnetometer. (PR#85174)
• Vishay VEML6031 Ambient Light Sensor (PR #85818)
• New stepper driver for Allegro A4979 microstepping motor driver (PR #86620)
• TDK ICM45686 IMU sensor (PR #85963)
• PAA3905 optical flow sensor (PR #86644)

Miscellaneous

• The deprecated KSCAN subsystem has now been completely dropped from the codebase, as the Input subsystem has been its replacement for quite a bit now. (PR #87353)
• A new code sample allows you to learn how to interact with stepper motors using the recently introduced Stepper subsystem. (PR #85757)
• The Zephyr Safety Working Group is making great progress gathering requirements, and you can see them at https://zephyrproject-rtos.github.io/reqmgmt/. Feel free to engage with the group through GitHub or via mailing list / Discord if you want to get involved!

A big thank you to the 48 individuals who had their first pull request accepted since Zephyr 4.1 was released, : @Abd002, @yyounxp, @lfilliot, @leonrinkel, @randyscott, @realhonbo, @mthiede-acn2, @tgcfoss, @skwort, @rdagher, @jangalda-nsc, @MichaelFeistETC, @elmo9999, @ecutm1, @nirav-agrawal, @AndreHeinemans-NXP, @XDjackieXD, @m-braunschweig, @rbudai98, @MJAS1, @DanTGL, @sctanf, @cylin-realtek, @ctourner, @WangHanChi, @dlim04, @verenascst, @Titan-Realtek, @Nitin-Pandey-01, @ckhardin, @Quizzarex, @zafersn, @thorsten-klein, @sgilbert182, @sayooj-aerlync, @tervonenja, @dewitt-garmin, @MyGh64605, @povsel, @sarchey, @etiennedm, @phb98, @petejohanson-adi, @Martdur, @ccpjboss, @JBarberU, @bia-bonobo, and @natto1784.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

I often get feedback along the lines of “We’re an online community, so how could we have a diversity issue? We don’t even know contributors’ gender, color, etc.!”, but the reality is that inclusion challenges can go much deeper than just gender or ethnicity. For example, some people might struggle engaging with the project due to not being comfortable with English, suffering from a disability preventing them to use some of the tools the project uses or recommends using, and so many other reasons…

This survey is a first step to better understand the diversity and inclusion issues in the Zephyr community, and an opportunity to hear about how some other projects/communities might be addressing these issues. Please take a few minutes to fill it out and share it with your friends and colleagues. The more responses we get, the better we can understand the issues and work on improving them.

And now for your weekly updates

New boards and SoCs

Only calling out a few of the new boards, but you might be interested in hearing that a new BeagleBoard joined the party, in the form of the BeagleY-AI, a pretty beefy, TI AM67A powered, board targeting the automotive market.

But also:

• ST Nucleo-F072RB,
• Oceanus-I EV from Würth Elektronik
• NXP MIMXRT700-EVK
• and many more!

New MCTP subsystem

MCTP (Management Component Transport Protocol) is a transport layer protocol designed for communication between various management controllers within a system. MCTP is independent of the physical layer, allowing it to operate over various transport mechanisms such as PCI Express, Ethernet, USB, and more.

Thanks to PR #75743 by @teburd, a new MCTP subsystem has been introduced. This subsystem leverages the capabilities of libmctp, an open-source implementation of the MCTP protocol, and initially integrates with Zephyr’s async UART API.

Drivers

• Microchip 10Base-T1S Ethernet PHY driver, supporting LAN865x and LAN867x PHYs (PR #81271 by @ParthibanI17164)
• AD4114 ADC Driver, which is a single supply, multichannel, 31.25 kSPS, 24-Bit, Sigma-Delta ADC working over SPI. (PR #82816 by @pcurt)

Miscellaneous

• Multiple updates have been made to try and improve our Contribution Guidelines to clarify expectations both from a reviewer and contributor perspective.
• A new code sample for using OpenThread’s CoAP API.

A big thank you to the 37 individuals who had their first pull request accepted since the last post, : @nhutnguyenkc, @yasinustunerg, @mcuxted, @ParthibanI17164, @ZiadElhanafy, @jhol, @tpennors, @aahmed-dewinelabs, @kbidani, @KevinTangDev, @nrbrook, @felf-zhaw, @kietavainen, @granquet, @srvanloon-priv, @nikolaptr, @CienetmarkChen, @ttwards, @narangmayank, @Jaakko-Bit, @Maartenwn, @iabdalkader, @DaGigabyte, @ofirshe, @pcurt, @gatzka, @CsBoBoNice, @td-pradecki, @ipankr, @gbmhunter, @lam-borg, @wwhheerree, @jacob-wienecke-nxp, @sebhub, @guenzel-kinexon, @silabs-BastienB, and @jcandkk.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

This week, I want to highlight two new boards (and their underlying SoCs) for which support was added in Zephyr during the last weeks of 2024, and that I know a lot of people have been eagerly waiting for. Namely, Raspberry Pi Pico 2 and WCH CH32V003EVT, are now officially supported in Zephyr… Happy New Year!

Raspberry Pi Pico 2

This has been a long time in the making but the latest addition to the series of supported Raspberry Pi boards in Zephyr—after the RP2040, a.k.a Pico, the Raspberry Pi 4 Model B and Raspberry Pi 5—is the Raspberry Pi Pico 2 and its RP2350 dual-core microcontroller.

Kudos to Andrew Featherstone for driving this effort and to everyone else who helped get this merged upstream through testing, reviews, etc.

WCH CH32V003EVT

RISC-V has been a hot topic in the Zephyr community pretty much from day 1, and when the WCH CH32V003 micro-controller appeared a little over two years ago, it was only a matter of time before someone would try to get Zephyr running on it

In case you’re not familiar, the CH32V003 is a RISC-V micro-controller that runs at up to 48 MHz, has 2 KB of SRAM and 16 KB of flash storage. So… pretty small, eh? What’s small, too, is its price: it sells for under $0.10!

As of last month, initial support for CH32V003 is now available, alongside the reference dev board, the CH32V003EVT. There is obviously not a lot that one can fit in just 2KB of RAM, but all basic peripherals are supported (clock, GPIO, PWM, UART, etc.), and more WCH pull requests are already lined up.

There are dozens of other boards being added to Zephyr every month, but I thought that these two were particularly noteworthy, and I am really looking forward to seeing what people will start running on them now that they support 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.

Catch up on all previous issues of the Zephyr Weekly Update:

Since it wouldn’t do justice to any of the features introduced over the past few months by cramming them all into one post, I decided to focus on some recent improvements to the Zephyr documentation that you ought to know about.

New board catalog

There are well over 600 boards supported in Zephyr, and until very recently we didn’t really provide an easy way for someone to easily get a sense of which boards were available for a given architecture or SoC family, or from a given vendor. Instead, one would be served with a ginormous “flat” list of hundreds of boards that was really hard to navigate.

With the new board catalog, you can now easily filter boards according to various criteria, and narrow down the list of 620+ boards to only the boards that you care about in just seconds.

And more is coming! This catalog will soon also allow you to do something that’s even more useful when prototyping a new project which is filtering by supported hardware capabilities (think: “I am looking for a board with a display, a Bluetooth chip, and from vendor Foo, what do you have in stock for me, Zephyr?”).

Towards Zephyrpedia?

You may have noticed that the documentation page for -most- boards recently changed.

That new card on the side of the page, similar to what you would find on Wikipedia, is a first step towards trying to provide more structure and uniformity to the documentation of the various boards supported in Zephyr and, more importantly, to make sure that every piece of information that can automatically be deduced from things like Devicetree, or the board hardware model, is used to generate the documentation.

The intent is to make it way less likely that things like the Supported Features section of a board’s doc page get outdated, since they will be generated from a single source of truth.

Finding the right code sample

We have nearly 500 different code samples so, as you might have experienced, it can sometimes be hard to find the right sample for your needs.

Somewhat similar to the board catalog, you can now quickly search for samples right from the samples index page. As a lot of effort was spent carefully reviewing the description of the samples, and making sure they contain the right keywords in them, you should be able to find what you’re looking for much more easily.

Try it for yourself, whether you care about mqtt, audio, servo, battery, or whatever else, you will hopefully find at least one sample that will help you get going!

What’s also new is that the README for each code sample now includes a button that can directly take you to the source code of said sample on Github!

C API tooltips

You may have noticed that the documentation of Zephyr’s C API is not “inlined” in the main documentation page anymore, and you may now refer directly to the Doxygen documentation to access the reference documentation of the various APIs.

However, in many cases you probably won’t have to leave the main Zephyr documentation since everytime an API is mentioned in the documentation, you can hover over it to get a tooltip which will directly show you the full Doxygen documentation of that API.

Where’s the driver for that compatible?

Often times, when adding or editing a node in your Devicetree, looking at the documentation of the binding properties is not enough to understand how the actual driver matching the node’s compatible makes use of the properties, and what behavior to expect.

From the Devicetree bindings documentation page, you may now click on the compatible you’re interested in and, alongside the documentation of the various binding properties, you can now actually go directly to the matching driver’s source code to see how it’s implemented. Handy, eh?

I am sure there are a lot more tips I could share, but I am also quite certain there are things you would like to see implemented in the documentation so please feel free to join the #documentation channel on Discord to get the conversation going!

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Manage your Zephyr SDK using West

I can’t believe we’ve lived all this years without such a command, but I am really glad it’s now available! While you typically don’t (re-)install the Zephyr SDK everyday, this is a task which can require quite a bit of work and be error-prone. And this is even more true for Zephyr newcomers, of course.

With the new west sdk command, one can now easily manage the download and installation of the Zephyr SDK. In most cases, it will just work and will, for example, automatically look for the latest version of the SDK.

The Zephyr Getting Started Guide should be updated shortly to take advantage of this new cool tool, but in the meantime I really encourage you to basically have a look at the various options documented via west sdk --help so that you keep the tool in mind for next time you need to tinker with your Zephyr SDK!

New performance profiling subsytem

We had two Zephyr Tech Talks in the recent past where we discussed tracing and profiling (check them out!) and the question that was asked first on both occasions was: what’s the performance impact on my application going to be if I enable tracing/profiling?

It is an important question since in most cases you don’t want the performance overhead to be such that it will completely change how your application behaves, for example due to tasks taking longer to do their job and causing changes in the scheduling.

A new profiling subsystem has recently been introduced with a first implementation of a very lightweight profiling mechanism that samples the stack trace at regular intervals.

Once a given configurable period has elapsed, you are able to retrieve the captured raw information, run it through a Python script, and then directly feed it into FlameGraph to get a visual representation of what your application has been busy doing during that time.

This provides you with a quick overview of what’s going on, and allows you to potentially spot unexpected bottlenecks, or a stack getting dangerously close to overflowing.

HTTP Server sample gets some nice improvements

The HTTP server sample has some new interesting features worth checking out, as it now serves new resources that demonstrates something closer to what you may be interested in doing for a real-life scenario.

More specifically the sample now serves a “home page” that’s much more useful as before, as it exercises HTTP resource handlers that are doing more than the simple “echo” service from before. Namely, there is now:

• a /led resource that can be POSTed to and will take JSON commands allowing to toggle an LED on or off. This is also a great way to get some concrete example of how JSON can be used in combination with the HTTP server library, as it’s definitely a common serialization format
• an improved WebSocket showcase since the web page can now show network traffic statistics in real-time, directly streamed from the Zephyr device to the browser.
• a new /uptime endpoint that serves the device uptime dynamically.

Give the code sample a try, I am pretty confident this will give you some inspiration

A big thank you to the 23 individuals who had their first pull request accepted since the last post : @maxdog988, @lucien-nxp, @thenguyenyf, @Stan-Corellium, @Yagoor, @tot0rokr, @Terezvent, @johankraft, @epc-ake, @deGerard, @marek14, @cyberjupiter, @wearyzen, @xiaolusu, @bianik, @zin-HXQ, @haduongquang, @krzysztofgawrys, @KushnerovMikhail, @tunguyen4585, @GrygiriiS, @esoutham-lvt, and @morihisa-momona.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

New Haptics driver class

It is common for interactive devices to provide haptic feedback to the user. For example, pressing widgets on a touch screen may trigger gentle vibrations while a stronger vibration may indicate that the action was not successful. Well, as of this week, Zephyr supports haptic feedback devices through a new haptics driver class!

An IC providing haptic feedback functionality is typically hooked up to a tiny motor that will vibrate when a signal is sent to it. The actual vibration pattern can be controlled in several ways: directly feeding the IC with a PWM or analogue signal, using built-in “melodies” available from the chip’s ROM (ex. “strong click”, “short double click”, etc.), etc.

The new haptics driver class provides a common API for starting/stopping vibrations, and for now most of the actual configuration is done through hardware-specific API. (PR #76343)

Texas Instruments DRV2605 is the only driver implementing this API for now, but let’s hope we’ll get more in the near future.

I’ll try to prepare a short demo of this new feature for the next blog post, but you may check out this code sample in the meantime.

A practical State Machine Framework example

I have mentioned Zephyr’s State Machine Framework quite a bit in the past, and I am happy to see that more and more subsystems are either transitioning to it, or considering doing so. State machines are something you definitely don’t want to get wrong, and using a proven framework can really help with making your code easier to read, test, and maintain over time.

We have a new very cool code sample that implements a calculator with a fancy LVGL GUI and whose logic is implemented using the State Machine Framework.

It is really nice to see how to turn a pretty complex state machine into something that can actually be executed and hooked up to a UI. I hope this will inspire folks to look at SMF whenever they’re just about to get lost in switch/case madness

(PR #76465)

SoCs, Boards & Shields

Support has been added for the following SoCs:

• Several SoCs from Analog Devices’ DARWIN MAX326xx Series (MAX32662 , MAX32666, MAX32675). (PR #73578, #73560, #73576)
• FLPR (Fast Lightweight Processor) RISC-V core on nRF54H20 is now supported. (PR #75451)
• Wi-Fi driver for the NXP RW612 has been added. (PR #76289)

New boards and shields:

• The nRF7002 EK is a versatile evaluation kit in the form of an Arduino shield that can be used in Nordic and non-Nordic host boards. (PR #75714)

• 01space ESP32C3-0.42-OLED. (PR #74964)
• STM32F405 Core. (PR #74378)

Drivers

• New MBOX driver for ESP32. (PR #76301)
• New DMA driver for MAX32xxx. (PR #76627)

Miscellaneous

• Added support for Wi-Fi Device Provisioning Protocol (DPP) via hostap. DPP is a secure, simplified method for connecting devices to a Wi-Fi network without needing to share the network password directly. (PR #73707)
• A new reset_stats() API has been introduced to allow resetting Wi-Fi usage statistics. (PR #75768)
• New sample application demonstrating how to use the CoAP client. (PR #76069)
• LittleFS module has been updated to 2.9.3. (PR #74001)
• POSIX
  • Added support for _POSIX_THREAD_PRIO_PROTECT. (PR #74386)
  • Implemented readdir_r. (PR#74394)

A big thank you to the 16 individuals who had their first pull request accepted this week, : @alexstanoev-nordic, @nngt88, @pyadvichuk, @duynguyenxa, @juliaazziz, @LeoBRIANDSmile, @aa889788, @yiding, @konrad1s, @unsanded, @thales-nascimento, @pblxptr, @LiLongNXP, @Robibobo1, @asingh-GiN, and @00thirdeye00.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

It is a big milestone for the project and it brings a lot of new features and improvements which I’ve been covering in details in last week’s announcement blog post. I also had a lot of fun diving into some of the most significant changes and putting together this video that’s packed with in-depth demos of the new HTTP Server, Precision Time Protocol integration, and more.

As for this week’s news, just keep reading!

Rust coming to Zephyr?

The first few weeks after a major release are the perfect time for new significant features to be proposed, and this is exactly what is happening right now with the proposal to add Rust support to Zephyr.

RFC #65837 describes the bulk of the proposal and there’s now a number of pull requests with actual code and documentation that I highly encourage everyone to give a try.

#![no_std]

use zephyr::printkln;

extern crate zephyr;

#[no_mangle]
extern "C" fn rust_main() {
    printkln!("Hello world from Rust on {}",
              zephyr::kconfig::CONFIG_BOARD);
}

I am really excited to see all the work and discussions happening around the topic as this will be my excuse to finally learn Rust!

Interesting, and related: as of this week, probe-rs is a new supported runner which you can use to flash/debug a supported board. (PR #71627)

Upcoming Zephyr Tech Talk

Join me on Wednesday, August 7 (3.oo pm CEST / 9.00 am EDT) for a new Zephyr Tech Talk live stream! Katarzyna Zalewska will be back on the show and we will be discussing some of the best practices for monitoring the health of IoT devices in realtime.

You may join us from YouTube or LinkedIn, whichever you prefer

Boards & SoCs

Not an exhaustive list, but some of the new boards and shields recently added are:

• Added support for the Nucleo-H503RB board (PR #75590)
• Added support for Mikroe BLE TINY Click shield. (PR #76246)
• Added support for Adafruit Feather nrf52840 Sense. (PR #76135)

Drivers

• New driver for ST LSM9DS1 9-DOF IMU. (PR #73141)
• New RTC driver for Micro Crystal RV-8263-C8 . (PR #73385)
• New driver for Infineon CAT1 QSPI flash controller. (PR #73976)
• New True-RNG driver for Analog Device MAX32xxx SoC series. (PR #74943)

Miscellaneous

• HTTP server now allows to serve static resources directly from the file system. The content type of the resource is auto-guessed based on the file extension, and .gz files are also automatically treated as compressed content and HTTP headers set accordingly. Neat! (PR #76106)
• Emulated UART devices can now be added to a zephyr,uart-emul UART controller. (PR #75827)
• New LwM2M shell command (obs) to dig into active observations. (PR #74293)

A big thank you to the 23 individuals who had their first pull request accepted since Zephyr 3.7 was released, : @jacobw, @bas-archembedded, @dberlin, @alexstanoev-nordic, @maarten1C96, @SandraArrow, @Finwood, @juliaazziz, @LeoBRIANDSmile, @Finomnis, @anobli, @gschwaer, @WalkingTalkingPotato, @florolf, @thales-nascimento, @mrodgers-witekio, @VineetaNarkhede-eaton, @GaofengZhangNXP, @munir-zin, @olivier-le-sage, @00thirdeye00, @nordic-pikr, and @jsarha.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

MQTT-based sensor/actuator code samples

We have a new code sample that might be one of the most comprehensive to date in the Zephyr tree.

It demonstrates how to implement a simple IoT sensor that publishes sensor data over MQTT. IoT 101, you might say, but the sample is a great showcase of the many services one needs to support such a scenario, among which:

• Establishing network connectivity using DHCP ;
• Establishing a secure MQTT connection (using TLS 1.2) ;
• Using JSON to encode sensor data and send it at a user-defined interval (would be curious to see CBOR or other encoding formats introduced as alternatives) ;
• Subscribing to user-defined topic(s) on the MQTT server, e.g. to receive commands ;
• etc.

New SoC porting guide

A new documentation page describes the process of porting a new SoC to Zephyr.

This is a most welcome addition, that complements the existing architecture and board porting guides, and will be very useful for anyone looking to add support for a new SoC to Zephyr. (PR #69475)

Boards & SoCs

• Several additions to the list of peripherals supported for Renesas Smartbond SoCs: memory controller, added power management support to the crypto and MIPI DBI driver, … (PR #68023, #72994, #72819)
• Apollo 3 SoC series getting some love as well, with new counter driver (PR #72842), I2C (PR #72913), and watchdog (PR #72830)
• Added support for NXP Kinetis KE1xZ series. KE1xZ MCUs are based on a Cortex-M0+ core, running up to 96 MHz. These MCUs support up to 512 KB flash, 96 KB RAM, and a complete set of analog/digital features. (PR #71670)
• Added support for Microchip MEC5 SoC family. (PR #72876)

New boards and shields:

• Added support for NXP FRDM-RW612 board.
  The RW612 is a highly integrated, low-power tri-radio wireless MCU with an integrated 260 MHz ARM Cortex-M33 MCU and Wi-Fi 6 + Bluetooth Low Energy (LE) 5.3 / 802.15.4 radios. (PR #72306)
• Alongside KE1xZ SoC support, the NXP FRDM-KE15Z is now also supported. It contains a robust TSI (touch sensing interface) module with up to 50 channels, making it highly flexible for handling touch keys.
• USB device controller now available for nRF54H20 DK. (PR #72774)

Drivers

• It seems like the Video subsystem is getting some attention recently, and it is really nice to see a new driver just landed for the OV5640 CMOS 5-Megapixel image sensor. (PR #71854)
• New driver for Festo VEAA-X-3 series proportional pressure regulator. (PR #69047)
• New LED Strip driver for Texas Instruments TLC59731. TLC59731 is a 3-channel, 8-bit, PWM LED driver with single-wire interface based on the EasySet protocol. (PR #68617)

Miscellaneous

• A new rtt-console snippet has been introduced to quickly switch serial console output to Segger J-Link RTT.
• When using the sensor_shell code sample, you can now include a fake sensor implementation, which can help when you don’t have an actual sensor at hand (PR #72833)
• You may now enable CONFIG_EXCEPTION_STACK_TRACE_SYMTAB to have symbol names printed in stack traces on Arm64 and RISC-V. (PR #72973)
• Added a new module implementing MIPI STPv2 (System Trace Protocol). MIPI STP was developed as a generic base protocol that can be shared by multiple application-specific trace protocols. The new module can be used to decode a stream of STPv2 data. (PR #72151)
• Add a modem backend statistics module.
  Similar to how you can use kernel stats to e.g monitor how “high” your threads go, you can use this new module to keep an eye on buffer usage within the modem subsystem, and use the information to optimize their size. (PR #72576)

uart:~$ modem_stats buffer
ppp0_rx: used at most: 124 of 2048 (6%)
ppp0_tx: used at most: 2048 of 2048 (100%)
uart@b000_rx: used at most: 233 of 4096 (5%)
uart@b000_tx: used at most: 4062 of 4096 (99%)
cmux_rx: used at most: 124 of 2048 (6%)
cmux_tx: used at most: 2047 of 2048 (99%)
dlci_1_rx: used at most: 124 of 2048 (6%)
dlci_2_rx: used at most: 25 of 1024 (2%)

• Hierarchical state-machine operations in SMF (State Machine Framework) now follow a more “UML-like” transition flow. (PR #71729)
• New sys_bitarray_* APIs to now allow “popcount” (count how many bits are set), xor with another bitarray, as well as find the Nth bit set in a region. (PR #72901)
• New Kconfig, CONFIG_MEM_DOMAIN_ISOLATED_STACKS — on supported architectures, thread stacks within the same memory domains are now isolated, i.e. threads within the same memory domains have no access to others threads’ stacks.
• Added support for bt_disable in the ISO implementation. (PR #72690)
• west build now allows to pass the list of shield(s) you want to add to your board via the --shield argument — much more natural than the old way of passing -DSHIELD as a CMake parameter. (PR #72720)
• USB device “next” stack now has initial support for BOS (Binary Object Store). (PR #72215)

A big thank you to the 7 individuals who had their first pull request accepted this week, : @alex-bellon, @charliegilliland, @luqasn, @roger1wang-intel, @nicogrx, @zaporozhets, and @srmnw.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Extension developer kit for LLEXT

Introduced with the latest Zephyr 3.6 release, the LLEXT (Linkable Loadable Extension) subsystem has been gaining a lot of traction lately.

In many cases, people developing the “core” of a Zephyr application designed to be extensible (e.g. a smart home gateway with a fancy display allowing for news “apps” to be added) are not the same people that will be developing the extensions (e.g. an energy monitoring or a weather forecast application, to take the previous example). LLEXT extensions as usually meant as lightweight “plugins” that use a well-controlled and limited set of APIs ; therefore, asking developers to setup a full-blown Zephyr development environment is overkill and error-prone.

This is where the new LLEXT Extension Developer Kit (EDK) comes in: it simplifies the development of extensions outside of the Zephyr tree, by allowing to generate an “SDK” (using west build -t llext-edk target) that packages all the necessary headers and compile flags relevant in the context of a given Zephyr app, effectively providing extension developers with all they need to start hacking away!

Try out the new EDK code sample and see PR #69831 for more details.

Sysbuild multi-target sample

As a way to make it easier to grasp the concepts behind sysbuild, and how it can be used to build multiple facets of your application at once (ex. the actual Zephyr application alongside an MCUboot bootloader), a new “multitarget Hello World” code sample has been introduced.

It showcases a classical Hello World application, except that it also includes the configuration files and explanation on how to build it and flash it for multiple targets (ex. different SoC cores), also leveraging the new hardware model and board target terminology in the process. (PR #69652)

Boards & SoCs

• New ARM architecture Kconfig options CONFIG_ROMSTART_REGION_ADDRESS and CONFIG_ROMSTART_REGION_SIZE allow to relocate the rom_start region (that typically contains the boot-vector data and irq vectors) to a custom region. (PR #71684)
• Removed limitation to 4 CPUs for SMP on x86, and also updated Zephyr kernel limitation to 32 CPUs (instead of 8) in the meantime! (PR #60230)
• Power management support added to Renesas SmartBond UART. (PR #62190)
• Power management support added to NXP RW61 SoC series. (PR #72758)
• Added USB support for NXP MCX N947. (PR #72386)
• Added RTC alarm support for all STM32 MCU series. (PR #71957)

New boards and shields:

• The STWIN.box (a.k.a. STEVAL-STWINBX1) from STMicroelectronics packs an impressive amount of sensors (accelerometer, magnetometers, MEMS microphones, …) and has Wi-Fi, Bluetooth, and NFC connectivity as well. It is now supported in Zephyr (PR #72723)
• STM32H745I Discovery kit is a complete demonstration and development platform for STMicroelectronics Cortex-M4 and M7 based STM32H745XI MCU. (PR #72510)

Networking

• There is now a really great documentation page for the new HTTP server. It compliments the existing code sample quite well and really gives you all you need to know how to declare static resources, expose WebSocket endpoints, etc.
• A new net http shell command gives you the ability to get a quick snapshot of the HTTP resources currently available. (PR #72578)

Host:Port       Concurrent/Backlog        Resource type   Methods         Endpoint

192.0.2.1:80    1/10                      dynamic         GET,POST        /dynamic
                                          static          GET             /
                                          websocket       GET             /

1 service and 3 resources found.

• TLS sockets have been available and use in Zephyr for quite a while, so it was long time due that they’re no longer marked as “experimental)”. (PR #72482)

Drivers

• There were several improvements made to the LED strip driver class this week, including new API function to get the length of an LED strip at runtime, which is now also a mandatory binding property alongside color-ordering. (PR #71630)
• I2C driver for ESP32 now allows for clock speed to be configured at runtime. (PR #72380)
• Added support for GPIO for Apollo3 SoCs. (PR #72438)
• Added the ability to read the advanced capabilities (GETCAPS) of an I3C target. (PR #71792)
• Added DAC and ADC drivers for the General Analog Unit (GAU) peripheral as found on NXP RW SoCs. (PR #70506)
• New driver for Innovative Sensor Technology TSic xx6 temperature sensors. These are low-power, calibrated sensors with accuracy as high as ±0.07 °C at +20 °C. (PR#70432)
• Added support for DS18S20 High-Precision 1-Wire Digital Thermometer (maxim,ds18s20) to the existing DS18B20 driver. (PR #71286)

Bluetooth

• Bluetooth BAP (Basic Audio Profile) shell now supports receiving audio data from e.g. a PC over USB, and encoding it using LC3 before sending it. to BAP audio streams. (PR#71084)
• Added support for Hands-free Audio Gateway (AG), which can be enabled using CONFIG_BT_HFP_AG). The audio gateway profile allows the microphone/speakers of a Bluetooth device (ex. a computer) to be used as an audio input/output device for another Bluetooth device, such as a mobile phone. (PR #70532)
• Simplified Kconfig options and interface between the host and controller. (PR #72580)

Miscellaneous

• I think a lot of people don’t necessarily know it, but Zephyr has a complete State Machine Framework (SMF) that can greatly simplify the implementation of protocol stacks, graphical user interfaces, etc. There are a few places in Zephyr where SMF is being used, but until this week there was no dedicated sample showcasing SMF “on its own”. Thanks to an awesome contribution from Glenn Andrews, it’s not the case anymore, and I highly encourage you to check out this new sample! (PR #70921)
• A new build option, enabled via CONFIG_BUILD_OUTPUT_COMPRESS_DEBUG_SECTIONS, allows to compress debug sections and therefore reduce size of ELF files substantially. (PR #72436)
• As part of ongoing work to move away from TinyCrypt and towards PSA (#43712), MCUmgr switched to PSA for its crypto operations (ex. checksum and hash functions). (PR #71947)
• Added initial HID device support to the USB “next” stack. (PR #65801)
• Several welcome fixes and improvements were made to the scripts/footprint/size_report script. (PR #72316)
• When using deferred logging, new log_thread_trigger() API allows to essentially flush the log buffer by forcing the log thread to process any pending messages immediately. (PR #71530)
• nRF Services library is now available for the Nordic HAL. (PR #70245)

A big thank you to the 7 individuals who had their first pull request accepted this week, : @trunghieulenxp, @jlh-makeen, @darkmoon32, @AyushKot96, @mstumpf585, @dapperlo, and @Rafal-Nordic.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

It is really great to see the community coming together to share their experiences, and I highly encourage you to check out if there’s a meetup happening near you. If not, you may actually be interested in starting one yourself!

Next up is Cologne, where a second Zephyr meetup is already held after a very successful first edition a few months back!

Update to Python 3.10 as min version

A small but noteworthy change: ahead of the upcoming Long-Term Support version of Zephyr, and in order to make sure we support a minimum version of Python that’s consistent with their own LTS cycles, Zephyr now requires Python 3.10 as the minimum version. PR #72142

SoC-wide overlays

Historically, Devicetree/Kconfig overlays have always been board specific. With the introduction of the new hardware model, it is now possible to define overlays that apply to an entire SoC series, which can be really convenient, as illustrated with this recent update to the Wi-Fi code sample, which now doesn’t require zillions of repetitive overlays for all the different ESP-32 boards supported in-tree, but instead just a few only based on the actual SoCs.

Bash completion for Twister commands

I am frankly always struggling to know how to run Twister test suites from the command line, and I spend a ridiculous amount of time either going through my shell history or recent CI jobs to find the options I need. Therefore, I am really happy to see that there is now bash completion for Twister! (PR #72167)

Boards & SoCs

• Support has been added for Ambiq Apollo3 Blue and Apollo3 Blue Plus SoCs, alongside associated evaluation boards. Apollo3 Blue series are ultra-low power Cortex-M4F MCUs with an integrated Bluetooth 5 controller. (PR #67815)
• New MDIO driver (Management Data Input/Output) for STM32. (PR #71012)
• New video driver for STM32 Digital Camera Memory Interface (DCMI). (PR #71462)
• GCC toolchain configuration updated to support Arm Cortex-R82. (PR #72279)

New boards and shields:

• Added support for Croxel CX1825 Bluetooth prototyping board. (PR #71901)
• New shield defintion for Seeed Studio Round Display for Xiao. (PR #71239)
• A small yet noteworthy change to the STM32C0116-DK board definition added last week. This board features a 5‑way joystick hooked up to a single ADC input pin using a resistor ladder. The adc-keys driver allows to quickly define which voltage range corresponds to each key combination, making it straightforward to expose all the relevant key codes to the input subsystem. (PR #72315)

adc-keys {
	compatible = "adc-keys";
	io-channels = <&adc1 8>;
	keyup-threshold-mv = <3300>;

	select_key {
		press-thresholds-mv = <0>;
		zephyr,code = <INPUT_KEY_SELECT>;
	};

	left_key {
		press-thresholds-mv = <670>;
		zephyr,code = <INPUT_KEY_LEFT>;
	};

	// ...
};

Networking

• I mentioned it was coming last week… turns out it’s already there: the new HTTP server now supports WebSocket! (PR #72241)
• Added support for gratuitous ARP transmission. A device may send such a packet on a local network to announce or update its own IP-to-MAC address mapping. It’s particularly useful for ensuring that devices that frequently enter deep sleep mode are immediately recognized by their peers upon reconnection. (PR #71873)
• Added support for IPv6 Privacy Extension (RFC 8981). (PR #71996)
• Updated hostap module. (PR #71805)

Drivers

• New driver for Sequans GM02S cellular modem. (PR #72217)
• New driver for LuatOS Air530z GNSS receiver. (PR #72053)
• New driver for Texas Instruments INA226 bi-directional current/power monitor, which can be used to sense current/voltage on buses up to 36V. (PR #68368)
• New multi-function device driver for Analog Devices ADP5585 keypad decoder, I/O expander, and PWM generator. (PR #69330)
• New driver for IS66WVQ8M4 PSRAM. (PR #70620)
• Several cool improvements to GROW_R502A fingerprint sensor (why yes, Zephyr has support for fingerprint sensors, in case you didn’t know!). (PR #59654)

Miscellaneous

• Various Twister optimizations and speedups, which according to the author should speed up execution times by 5-7%. (PR #71694)
• Added support for Bluetooth Common Audio Profile Commander Reception start procedure. (PR #69593)
• A couple new useful shell commands:
  • The GPIO shell module now features a toggle command to… toggle a GPIO :). (PR #72362)
  • The I2C shell module now has a direct_read command, which reads directly from the I2C device without first writing a register address. (PR #71928)

A big thank you to the 11 individuals who had their first pull request accepted this week, : @bogdanovs, @smaerup, @debbiemartinarm, @vThibo, @louis-feller, @RafaelLaya, @russkel, @davidschneider-cpi, @markaj-nordic, @schumphi, and @AlessandroLuo.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

There were some truly great sessions (and speakers!) and there is a very good chance that you will want to catch up and watch all of them if you didn’t have a chance to attend in person!

HTTP Server

This week’s big update is the addition of a long awaited HTTP server library. It supports HTTP/1.1 as well as HTTP/2, with or without TLS, and WebSocket support should be coming shortly! This has been a multi-month effort that started last year as a Google Summer of Code project from Emna Rekik.

Similar to the socket and CoAP services, adding new HTTP resources can easily be done, with very little overhead, not so differently from how you would do it in a higher-level language like Python or JavaScript!

struct http_resource_detail_static index_html_gz_resource_detail = {
	.common = {
			.type = HTTP_RESOURCE_TYPE_STATIC,
			.bitmask_of_supported_http_methods = BIT(HTTP_GET),
			.content_encoding = "gzip",
		},
	.static_data = index_html_gz,
	.static_data_len = sizeof(index_html_gz),
};

HTTP_RESOURCE_DEFINE(index_html_gz_resource, test_http_service, "/",
		     &index_html_gz_resource_detail);

I highly recommend you dive into the new code sample that will tell you a lot more about the various capabilities of this new service, including how to configure it, or even to profile it.

Power Management for dummies using the Zephyr shell

You’ve heard me praise the Zephyr shell many times before. It is an awesome resource to quickly troubleshoot your system and interact with all your peripherals and subsystems without having to write any code.

A new pm shell module has been introduced to let you interact with the power management subsystem using simple commands. Assuming that power management is indeed enabled in your Zephyr application, you can now do things like pm suspend mydevice to quickly suspend a device.

What’s more, device list, which might be one of the most useful commands in the Zephyr now also gives you feedback regarding the actual PM mode of all the devices in your system:

uart:~$ device list
devices:
- i2c@40003000 (active)
- buttons (active, usage=1)
- leds (READY)

In this example, leds is a device that does not support PM, i2c supports PM with manual suspend and resume actions and is currently active, and buttons supports runtime PM, is currently active and “used” by one user.

As part of introducing all these great commands, Fabio has also added a new callback that a shell module might implement to make tab-completion for device names smarter. In the context of the new pm shell command mentioned before, it means that only devices that do support power management will be suggested when you hit TAB!

Please check out PR #72037 and update your shell modules accordingly

Boards & SoCs

• Added MMC driver for RCAR. (PR #60285)
• Added TPM counter support on i.MX93 Cortex-A Core. (PR #70714)
• Added RTC driver for Nuvoton Numaker m46x. (PR #71929)
• Added ADC driver for Nuvoton numaker m2l31x. (PR#71267)
• Added SDHC driver for ESP32. (PR #71165)

New boards:

• MikroElektronika Weather Click shield, which features Bosch BME280 sensor (humidity, pressure, temperature). (PR #71076)
• STM32C0116 DK, a development board for the STM32C0 series of MCUs — Cortex-M0+ with 32K of Flash, 6K of RAM, a Grove connector, a 5-way joystick, … (PR #71722)

Drivers

• Texas Instruments TMP114 is an ultra-thin, high accuracy, I2C temperature sensor with a 16-bit ADC and an accuracy of ±0.2°C. (PR #71964)

Miscellaneous

• Added support for LoRaWAN Fragmented Data Block Transport Service. Being able to transmit fragmented blocks of data over an otherwise very constrained network in terms of MTU means essentially unlocking the ability to perform firmware upgrades over-the-air. (PR #68570)
• New ability for west to run some commands (e.g. erase, recover) only once, either at the beginning or at the end of the programming of a board when using sysbuild. This allows to e.g. only erase the flash once when targeting a multi-core SoC. More documentation available here. (PR #69748)
• Added support for EUI64 device identifiers in hwinfo. (PR#72057)
• New code samples for the I2C Target API. (PR #72103)
• New settings_save_subtree() API allows to only save items from a settings subtree that are different from their persisted value. (PR #72113)

A big thank you to the 9 individuals who had their first pull request accepted this week, : @swift-tk, @DeHess, @dalprahcd, @0x6e, @fgihl, @bogdanm, @tychofrei02, @JefersonFernando, and @kail.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Speaking of in-person events, you have only a few days left to apply to speak at the upcoming Zephyr Developer Summit Europe 2024, held as part of the Open Source Summit 2024 in Vienna, Austria, on September 16-18!

Deferred device initialization

There have been many discussions in the past few months around improving the flexibility of Zephyr device model, in particular around making it possible to defer the initialization of a device. There are many reasons why one may want to decouple the instantiation of a device from its actual initialization, and whether a device should actually be fully initialized is often a decision worth making at runtime (ex. several devices may be sharing common resources, and only one such device may be actually active at a given point in time).

Now that pull request #67335 has been merged, any device may use the zephyr,deferred-init property in Devicetree to indicate they shouldn’t be automatically initialized but, rather, leave this step to the discretion of the programmer by means of the new device_init() API.

Relocation of ARM ELF binaries

In the context of LLEXT (linkable loadable extensions), it is important for Zephyr to be able to process an ELF binary “on the fly” as it needs to relocate the various sections of the file to the proper memory sections. PR #70452 introduced support for all the relocation types for ARM ELF files (i.e. partial and shared linking are now also properlu supported) making it possible to address even more scenarios which, if you think about the new “deferred initialization” mode, may very well include dynamically loading new device drivers in the not so distant future

Boards & SoCs

As there were a lot of things happening over the past three weeks, this section really focuses on the main highlights — please don’t be mad at me if I forgot something significant (and please comment to help correct the mistake!).

• Historically, running Zephyr application on Espressif ESP32 devices involved a second-stage bootloader as the initial bootloader was always the ESP-IDF bootloader. A new “simple boot” mode now allows to build applications that don’t require this second-stage bootloading. This makes for optimized memory and size, and is now the default option when building for ESP32, but MCUboot remains a possible alternative. (PR #70505)
• Renesas SmartBond SoCs now have power management support, and MCU can now enter low-power mode when needed. (PR #61857)
• Frame-pointer based stack unwinding for RISC-V architecture. (PR #69912)
• Improved coredump for RISC-V 64 bits: it now includes all the registers. (PR #70949)

There’s quite a few new boards whose support has been added, including:

• Raspberry Pi 5. (PR #70538)
• Arduino UNO R4 WiFi. (PR #71041)
• STM32L152C Discovery kit. (PR #70765)
• Renesas R-CAR Spider S4 (ARM64). (PR #68141)
• ESP32-S2 and ESP32-S3 Devkit-C. (PR #66462 and #66463)
• Phytec phyBOARD-Electra AM64x. (PR #70965)
• Waveshare ESP32-S3-Touch-LCD-1.28. (PR #67311)

Drivers

• Added a driver for the output diagnostics of the TLE9104 low-side switch. (PR #67029)
• New driver for CHSC6X round display controller, found e.g. on the Seeed Studio Round Display for XIAO. (PR #71073)
• Add support for half-duplex (3-wire) to the SPI controller driver for Raspberry Pi Pico. (PR#69634)
• New input driver for PAW32XX mouse sensors. (PR #71716)
• New driver for Analog Devices AD569x series of low-power output DACs. (PR #71338)
• New loopback disk driver allowing to transparently read/write from/to a file on the filesystem. (PR #69895)
• New driver for ST7796S LCD display controller. (PR #69991)
• Added Altera FPGA bridge support. (PR #71360)
• New I3C driver for Nuvoton NPCX SoCs. (PR #71366)
• Added Murata NCP15XH103 compensation table to generic thermistor driver. (PR #70912)

Miscellaneous

• For architecture that have MMU supported (and enabled!), it is now possible to memory map thread stacks, making it possible to create guard pages that can help catching stack overflows/underflows. (PR #70810)
• A lot of work is going into the Eclipse hawkBit client, to make it more configurable. (see e.g. PR #68806)
• High-speed support has been improved in the new USB device stack, and it’s now USB 2.0 compliant. (PR #67749)
• A new I3C shell module has been introduced. (PR #70773)
• west’s built-in support for generating SPDX SBOM files has been updated to now support SPDX 2.3 (vs. 2.2 before). The main addition is the ability to indicate the PrimaryPackagePurpose for each package. (PR #70581)
• The Wi-Fi shell module now allows to configure multiple security modes for each network. (PR #71044)
• The code samples for Bluetooth Heartrate monitor have been updated to support extended advertising and hence be long-range compatible on SoCs that support Bluetooth Low Energy Coded PHY. (PR #70257)

A big thank you to the 31 individuals who had their first pull request accepted since my last post, : @arnebdr, @ahaslam2, @achech, @Lahyllas, @ulmanyar, @lkoudelka, @franc0is, @nicogou, @lluiscampos, @jan-kubiznak, @petarsusac, @adityaganesh, @erang20, @nordic-bami, @hardeepsharma95, @ke6zfi, @alvsun, @hansbinderup, @rob-the-dude, @orangecms, @selescop, @doeni98, @jomigo96, @nxpadamm, @nlebedenco, @ABESTM, @SaintNicholas, @gkrulce, @nordic-babu, @raintamer, and @DmytroYaskov.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

In case you missed it, I highly recommend you catch up the recording of this week’s Zephyr Tech Talk. We discussed the new hardware model introduced for the upcoming Zephyr 3.7 release, the kind of use cases it allows to address, and what you need to do to migrate your existing board definitions. We had well over 200 people attending—a record!

And now, for some of the things that recently landed in the main Zephyr tree…

Use host networking stack in native simulator

The native simulator is getting a lot of love recently, and a noteworthy improvement is the fact that there is now a way to directly use the host’s networking stack, which means it’s now much easier to leverage networking in the simulator, without having to rely on TUN/TAP interfaces and error-prone configuration scripts.

Read more in the documentation of the native simulator. (PR #65116)

“Cooked mode” capture

On the topic of networking, it is now possible to perform so-called “cooked mode capture” of network traffic. In a nutshell, this means that it’s now possible to capture the packets that are being sent and received by the Zephyr networking stack without requiring a physical network interface to be present.

More details on how this works in the documentation, as well as the dedicated net-capture code sample. (PR #70926)

Boards & SoCs

• Seeed Studio XIAO Expansion Board is a cheap yet very complete expansion shield for boards with the XIAO form factor. It includes an OLED display, a microSD card slot, an RTC, and plenty of Grove connectors. Thanks Charles for adding support for it in(PR #69999!
• ST B-LCD40-DSI1 is a shield with a 4″ WVGA TFT LCD with MIPI DSI interface and a capacitive touchscreen. (PR #70350)
• WeAct Studio MiniSTM32H743 Core board features a STM32H743VIT6 (Cortex-M7 @ 480 MHz), 2MB of Flash, and 2x 8MB of external Flash. (PR #69267)
• M5Stack ATOM Lite is a tiny ESP32-PICO-D4 based devkit with an RGB LED, an infra-red LED, and a Grove connector. The really small form factor makes it one of my favorite targets for quick ESP32 tests. (PR #68190)
• Several new drivers for some NXP peripherals:
  • ESAI (Enhanced Serial Audio Interface), used for serial communication with e.g. DSPs, S/PDIF transceivers, … (PR #68875)
  • ENET QOS (Ethernet QoS).(PR #70637)
  • hwinfo now available for RW SoCs. (PR #70456)

General drivers

• STTS22H is an ultralow-power, high-accuracy, digital temperature sensor, with an operating range of -40 °C to +125 °C. (PR #68356)
• Aosong DHT20 temperature and humidity sensor (sometimes found as Aosong AHT20, or Aosong AM2301B, don’t ask me why). (PR #67279)
• Angst+Pfister oxygen sensors from the MDLx5 series. (ex. FCX-MLD25 & FCX-MLD95). (PR #68689)
• onsemi MT9M114 is a 1/6″ 1.26 Megapixel CMOS digital image sensor and the Zephyr driver for it was significantly reworked to improve framerate and support more resolutions. (PR #70237)
• Cellular modem drivers can now expose IMEI and ICCID info. (PR #69217)
• New GNSS Driver for U-BLOX M10. (PR #68350)
• New driver for Sitronix CF1133 touchscreen controller. (PR #68321)
• New driver for Cirque Pinnacle 1CA027 trackpads. (PR #69438)
• ST LIS2DUX12 accelerometer (ultralow-power 3-axis smart accelerometer, with anti-aliasing filter) is now supported. (PR #65259)
• Existing MPU6050 has been reworked to now also support MPU6500. (PR #70130)

Miscellaneous

• LVGL module has been updated to v8.4.0, and LVGL 9 support is imminent! (PR #70470)
• A significant overhaul of the Virtual LAN (VLAN) implementation . (PR #70345)
• CONFIG_NET_SOCKETS_POSIX_NAMES Kconfig option is being deprecated. You can read more about why in the migration guide entry that was created for this change. (PR #69950)
• ram_report and rom_report West targets now show the address of the objects in the output reports. (PR #69542)
• RTT Shell backend now detects the presence of a host, preventing deadlocks in situations where the shell would end up continually writing to RTT. (PR #68941)
• Added support to configure BSSID in Wi-Fi connect command. (PR #70024)
• mDNS responder used to make it mandatory to have all the records set at compile time. It is now possible to provide the records at runtime. (PR #60271)
• POSIX:
  • Added support for clock_getres(). (PR #70525)
  • Added support for pthread_rwlockattr_setpshared(). (PR #70421)
  • Added support for pthread_attr_getinheritsched() and pthread_attr_setinheritsched(). (PR #68470)
  • Added support for pthread_setschedprio(). (PR #71001)
  • Added missing implementations for POSIX networking API calls. (PR #70635)

A big thank you to the 24 individuals who had their first pull request accepted in the past couple weeks, : @mayankmahajan-nxp, @swkim101, @fpistm, @erian747, @zakport, @benni44, @clemdy, @ZhaoxiangJin, @zejiang0jason, @akscram, @RickBruyninckx, @kdunn926, @raffarost, @jatedev, @cliu5764, @glneo, @23131dw, @HesselM, @arikgreen, @ringlej, @bmulder-innoseis, @mdubielx, @ct-fk, and @javanlacerda.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Using CLion for Zephyr development

There is always a lot of questions from people new to Zephyr on what IDE they should be using (if any), and suggestions for setting it up for Zephyr development.

It is really nice to see that the folks over at JetBrains took some time to document the instructions for using CLion to develop and debug Zephyr application, and I really encourage you to give them a try!

UART over Bluetooth LE

You may remember the Zephyr Tech Talk episode from a few weeks back where Luis Ubieda presented the work he’s been doing around making it easier to use UART over Bluetooth LE.

With PR #69881, a new implementation of Nordic UART Service (NUS) is provided. It essentially exposes to characteristics for RX/TX, allowing to mimic a UART over BLE.

A dedicated nus-console snippet makes it really easy to user UART over BLE for the Zephyr console, by allowing to redirect serial console output to a UART over NUS Devicetree instance.

MPU Support on Xtensa

MMU support was added a little while back, and it’s great to see that MPU (Memory Protection Unit) is now supported on Xtensa architectures.

PR #67938.

Boards & SoCs

• Nuvoton NuMaker M2L31KI evaluation board is a Cortex-M23 based development board running at 72MHz and targeting IoT applications. (PR #70357)
• Pin mappings for ST Morpho connector of supported STM32 Nucleo G0 boards have been added with PR #69693.
• Many new peripherals have been added to the NXP RW612 SoC port, from DMA to Flash driver, counters, I2C, …. (see e.g. PR #70192)

General drivers

There were several interesting improvements around Ethernet support:

• You can now use Ethernet drivers in “raw” mode (i.e. without building the L2 layer / MAC support). See CONFIG_ETH_DRIVER_RAW_MODE. (PR #70030)
• It is now possible to do Ethernet MAC address filtering. (PR #69385)

And also:

• MAX31790 is a 6-Channel PWM Fan RPM Controller. The existing PWM controller driver has been extended to now be a “multi-function device” (MFD) driver that also allows to access the “sensor” side of this IC, i.e retrieve the fan speed and fan fault information for each channel.
• The new-ish driver for the Pixart PMW3610DM (low-power laser mouse sensor) now exposes more configuration options, ex. to set the resolution, enable “smart mode”, etc.). (PR #70248)

Miscellaneous

• Zephyr API overview documentation page now indicates the stability level of each API. There are still many instances where the information is missing but surfacing this information will make it easier to improve and clean it up over time. (PR #61994)
• In order to help not flood logs with log messages that are repetitive, new LOG_WARN_ONCE() macro will write a WARNING level message to the log on the first execution only. (PR #70282)
• Ahead of the upcoming Zephyr Tech Talk about the new hardware model, some great work was done to explain the terminology inherent to SoCs and boards in the context of Zephyr. (PR #69802)

• Percepio module has been updated to use TraceRecorder v4.8.2 and DevAlert (DFM) v2.1.0. (PR #68490)
• POSIX:
  • Added support for pthread_attr_getscope() and pthread_attr_setscope(). (PR#68450)
  • Added support for confstr(). (PR #70274)

A big thank you to the 10 individuals who had their first pull request accepted this week, : @MarinaKalashina, @Arunmanialagarsamy, @vidarbe, @SamyFrancelet, @su47flying, @grb72t3yde, @ad8sweera, @jgenssler-GiN, @ldaj00, and @eriktamlin.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Join us to understand the rationale behind this massive overhaul of the legacy model, and bring all the questions you may have, in particular with regards to migrating existing board definitions that you might be maintaining for your own projects.

Boards & SoCs

Now that the new hardware model has been rolled out, there’s quite a few new boards and SoCs that were waiting for it that could finally get merged. See for yourself:

• The NXP RW SoC series provides highly integrated wireless (Wi-Fi, BLE, and 802.15.4) MCUs, and PR #69943 introduced support for it in Zephyr. The board definition for RW612 has also been added. This chip is typically sold by module manufacturer such as u-blox, Murata, etc. as a standalone, ready-to-use, wireless module.
• FRDM-MCXN947 is a compact and scalable development board for rapid prototyping of MCX N94 and N54 MCUs. It is now supported in Zephyr. (PR #69890)
• Starfive VisionFive2 is a high-performance 64-bit RISC-V single board computer (SBC) with an integrated GPU. (PR #69814)
• ST25DV-DISCOVERY is a demonstration kit to evaluate the features and capabilities of the ST25DV series. Eve Redero contributed support for this board and I highly encourage you to also read the detailed write-up about the whole process. (PR #70010)
• Numaker M2L31 SoC series is based on an Arm Cortex-M23 core running at up to 72 MHz, 64 to 512 Kb of ReRAM, and 40 to 168 Kb of SRAM. Typical applications include motor control, PC peripherals, battery management systems, etc. (PR #69778)
• Adafruit 5×5 NeoPixel Grid BFF is a small shield that can stack on top of QT Py or XIAO boards and features 25 NeoPixel LEDs. It is now supported both as a “classic” LED strip, but also as a display controller using the LED matrix driver introduced last week! (PR #67610)
• Support for DPPIC (Distributed Programmable Peripheral Interconnect Controller) and IPCT ((Interprocessor Communication Transceiver) peripherals has been added for Nordic Semiconductor nRF54H20. (PR #69811)
• The STM32 SDMMC driver now also supports eMMC. (PR #69836)
• New generic driver for NXP MCUX FlexIO. (PR #53748)
• Support for external NOR flash has been added to FANKE FK7B0M1-VBT6. (PR #68442)
• I2C support has been enabled on STM32H5 boards. (PR #69094)

General drivers

• HL7800 cellular modem now supports PPP and CMUX, with the Pinnacle 100 DVK and MG100 from Laird Connectivity (now Ezurio!) updated accordingly. (PR #70060)
• Added support for minimum supported bitrates in CAN drivers. (PR #69533)
• ESP32 Ethernet driver now supports setting the MAC address at runtime. (PR #69869)
• Microchip XEC series KSCAN driver has been converted to use the input subsystem and common keyboard matrix library. (PR #65162)
• STM32 HCI Bluetooth driver now supports raw mode. (PR #69623)
• New ADC_DT_SPEC_*_BY_NAME() macros allow to get ADC io-channel information from devicetree by name. (PR #68247)

Miscellaneous

• west flash and west debugserver commands can now be used with the native_sim board. (PR #68835)
• The network logging (syslog) backend now supports TCP in addition to UDP. (PR #68307)
  • Since the DHCP protocol allows to provide the address of a syslog server as part of the lease (option 7), the new CONFIG_LOG_BACKEND_NET_USE_DHCPV4_OPTION option allows to automatically set the syslog server address when the Log Server option is set by the DHCP server. (PR #69328)
• Telnet shell backend has been refactored to use the new Socket service library. (PR #69612)
• Stereo support has been added to the Bluetooh LE audio broadcast sink sample. (PR #69341)
• “Change Microphone Gain” procedure has been implemeted in the Bluetooth CAP commander. (PR #66748)
• Bluetooth CAP shell module now properly supports broadcast commands. (PR #68550)
• New sys_slist_find() method to find an item in a singly linked list without removing it. (PR #66621)
• POSIX:
  • Added support for getmsg() and getpmsg() (PR #68516)
  • Added a “small” runtime implementation for sysconf() (PR #69882)

A big thank you to the 13 individuals who had their first pull request accepted this week, : @ene-steven, @KyleKotowick, @poialex, @alpineisle, @krisnaresi, @kurtjd, @nordic-segl, @michalek-no, @GRobertZieba, @sasataku, @kica-z, @grahas, and @marwaiehm-st.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

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>;
    circulative;
    start-from-right;
};

(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)

Miscellaneous

• 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!

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.

Catch up on all previous issues of the Zephyr Weekly Update:

I also encourage you to check out our special Zephyr Tech Talk episode earlier this week!

Zephyr 3.7, which will be the next Long-Term Support version of the project, is already starting to shape up, and below are some of the highlights from the first couple hundreds of commits already merged into the main branch.

Native UART TTY driver now supports interrupt-driven API

In an effort to make it increasingly easier to emulate Zephyr on host systems, the native UART TTY driver now supports an interrupt-driven API. In order to use the new driver for your zephyr,native-tty-uart UARTs, you may simply enable CONFIG_UART_INTERRUPT_DRIVEN in your project configuration.

I find it particularly interesting as this means that it’s now easier to e.g. simulate a GNSS receiver on your host system, by attaching your Zephyr app to a virtual UART into which you can inject your mock NMEA sentences. (PR #68857).

Boards & SoCs

As the project is in the process of transitioning to a new model for describing the SoCs and boards in the source tree, no work has been merged in the main branch this week.

The maintainers are holding off with adding new boards/SoCs and making changes in main until the working branch (collab-hwm) where the migration is happening is ready to be merged (which should be very soon).

General drivers

• An interesting new input driver allows to define input keys that are implemented using an ADC and a resistor ladder.

This is a pretty clever way to add multiple buttons while only using a single ADC channel, and the driver allows to basically define the mapping of how each ADC values / voltage ranges correspond to each key, or key combination. (PR #68446)

/ {
        buttons {
                compatible = "adc-keys";
                io-channels = <&adc 2>;
                keyup-threshold-mv = <0>;
                key_0 {
                        press-thresholds-mv = <1650>,  /* KEY0 */
                                              <2536>;  /* KEY0 + KEY1 */
                        zephyr,code = <INPUT_KEY_0>;
                };
                key_1 {
                        press-thresholds-mv = <2300>,  /* KEY1 */
                                              <2536>;  /* KEY0 + KEY1 */
                        zephyr,code = <INPUT_KEY_1>;
                };
        };
};

• RRAM (or ReRAM, Resistive Random-Access Memory) is a type of non-volatile memory that stores data by changing the resistance across a dielectric solid-state material. It’s a relatively new technology and one of its benefit is that it is several orders of magnitude faster than flash memory.
  A new flash driver for the RRAM controller found on some Nordic nRF SoCs has been contributed this week. (PR #68309)
• New regulator driver for the Cirrus CP9314 buck switched capacitor DC/DC Converter (cirrus,cp9314). (PR #68177)
• New driver for the ScioSense ENS160 environmental, multi-gas, sensor (sciosense,ens160). This sensor allows to measure CO2, VOC, as well as a general air quality index (AQI). (PR #67343)
• The PixArt PAT9125EL is a low-power optical tracking sensor that doesn’t require a lens to work, and a new input driver for it has been added (pixart,pat912x)!
  This sensor is particularly well suited for tracking movement over a shiny/glossy surface. (PR #69492)

• The charger subsystem now allows to define output limits for the discharge rate and the system voltage, allowing to issue alerts when these limits are reached. (PR #67810)
• The Ethernet driver for the W5500 now supports link status detection. (PR #68752)
• The ESP-AT Wi-Fi driver now allows to bind and receive from UDP sockets. (PR #68586)

Miscellaneous

• Various improvements to the DHCPv4 server.
• New lwm2m_set_bulk() API allows to set multiple resource values at once. (PR #68988)
• New network shell command (net iface set_ipv4_gateway) allows to set the IPv4 gateway of a network interface. (PR #68465)
• It is now possible to use CONFIG_SHELL_MSG_CMD_NOT_FOUND and SHELL_MSG_SPECIFY_SUBCOMMAND to indicate what message (if any) will be printed when a given command or subcommand is not found. (PR #69002)
• New sign_extend() and sign_extend_64() helper functions to perform sign extensions. (PR #68828)
• Bluetooth CAP Commander now supports the “Change Volume Mute State” procedure. (PR #66281)
• New POSIX APIs:
  • fattach()
  • fdetach()
  • syslog() (PR #68515)

A big thank you to the 16 individuals who had their first pull request accepted this week, : @JayHCloud, @bmihelcic, @thompsa, @jaz1-nordic, @vshymanskyy, @rntsoma, @sageve, @jerome-pouiller, @ngphibang, @celinakalus, @MaochenWang1, @allemanm, @Brianmm94, @rysiof, @jpanisbl, and @cmrdrbz.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Second round of updates to the Sensing API

PR #64478 has introduced another round of updates to the Sensing API. I haven’t had time to look into all the details so I encourage you to look at the changes directly in the PR.

As a reminder, there is now also a Sensors Working Group that meets every Monday to discuss all things sensors.

Boards & SoCs

• The SDP-K1 evaluation board from Analog Devices (ADI) is a system demonstration platform (SDP) designed to connect to various evaluation shields containing ADI components. (PR #67278)
• The STM32WB5MM-DK Discovery Kit is a dev kit for the STM32W5MMG module (dual core Cortex-M4/Cortex-M0+) that comes with an ultra-low-power BLE 5.2 / 802.15.4 radio module, an LCD display, 16MB of external Flash, and a couple of on-board sensors. (PR #67819)
• All ESP32 boards saw a significant decrease of their minimal heap size thanks to PR #67787.

SoC driver updates

• Clock initialization has been reworked across all Microchip/Atmel SAM SoCs. (PR #66499)
• Suspend-to-RAM support has been added for STM32. (PR #67534)
• New driver for NXP enhanced Direct Memory Access (eDMA). (PR #65671)
• Driver for Microchip/Atmel SAM flash controller has been redesigned to fully utilize the flash page layout and capabilities of each individual SoC. (PR #64215)

General drivers

• A new display driver is available for the Galaxy Core GC9A01A display controller, used to drive many round LCD displays these days (at least the ones from AliExpress ^^), like the ones used for smart watches and smart dials. (PR #67012)
• Bosch BMP581 is a barometric pressure sensor with high accuracy that can be used for e.g. fitness tracking use cases where detecting a change of altitude is required.
  With an average current consumption of 1.3 µA @ 1 Hz, it definitely qualifies as a low-power sensor :). (PR #61535)
• The driver for BD8LB600FS 8-channel low-side switch now supports daisy-chaining. (PR #65982)
• New Kconfig options (CONFIG_POWER_DOMAIN_*_INIT_PRIORITY) have been introduced to allow changing the initialization priority of power domains. (PR #67939)
• A noteworthy breaking API change in the CAN drivers: it is no longer possible to perform run-time filtering of frames based on the Remote Transmission Request bit, and filtering is now instead configured via Kconfig. (PR #67127)

Input drivers

This week’s numerous updates to the input subsystem make for a perfect excuse to shamelessly plug the recent Zephyr Tech Talk with ZMK firmware creator Pete Johanson. Whether you are a mechanical keyboard aficionado or simply curious about hearing how Zephyr was put to good use to enable custom keyboard firmware creation, check it out!

• Optical encoders are now supported. (PR #66121)
• A new keymap driver allows to use a Devicetree node to provide the mapping between your keyboard matrix and the actual keys at each row/column intersection. (PR #67757)

kbd {
      ...
      keymap {
          compatible = "input-keymap";
          keymap = <
              MATRIX_KEY(0, 0, INPUT_KEY_1)
              MATRIX_KEY(0, 1, INPUT_KEY_2)
              MATRIX_KEY(0, 2, INPUT_KEY_3)
              MATRIX_KEY(1, 0, INPUT_KEY_4)
              MATRIX_KEY(1, 1, INPUT_KEY_5)
              MATRIX_KEY(1, 2, INPUT_KEY_6)
              MATRIX_KEY(2, 0, INPUT_KEY_7)
              MATRIX_KEY(2, 1, INPUT_KEY_8)
              MATRIX_KEY(2, 2, INPUT_KEY_9)
          >;
          row-size = <3>;
          col-size = <3>;
      };
  };

• New helper functions have been added to convert Zephyr input codes into USB HID codes, see input_to_hid_code(), input_to_hid_modifier(). (PR #67862)

Miscellaneous

• Starting with GCC 10, GCC ships with a static analyzer. It is now possible to use Zephyr’s static code analysis infrastructure to easily run GCC static analyzer for your application, simply pass the following parameter when running west build: -DZEPHYR_SCA_VARIANT=gcc. (PR #64595)
• It is now really easy to build an LLEXT (Linkable Loadable Extension) module thanks to a new add_llext_target() CMake function.
  See the CMakeLists.txt file of the Hello World sample to see how to use it. (PR #67431)
• New CMake helper function (zephyr_blobs_verify()) allows to verify that blobs fetched using west have a valid checksum. (PR #67593)
• New APIs allow to check if an IPv6 address is link local or global, see net_ipv6_is_sl_addr() and net_ipv6_is_global_addr(). (PR #67838)
• A bunch of modules were updated this week:
  • LVGL version has been updated to 8.3.11, with 9.0.0 coming shortly as it’s just been released this week! (PR #66314)
  • zcbor version has been updated to 0.8.0. (PR #67418)
  • LittleFS version has been updated to 2.8.1. (PR #65414)
  • picolibc version has been updated to 1.8.6 (PR #67891)
• Added support for Wi-Fi STA disconnection. (PR #68007)
• New POSIX APIs:
  • mq_notify()

A big thank you to the 8 individuals who had their first pull request accepted this week, : @renpytom, @javad123javad, @itmm, @tanmaykathpalia, @msalau, @73jn, @sandip-dalvi, and @adri1mart1.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

On the topic of security, I really encourage everyone to watch our latest Zephyr Tech Talk, if you missed the opportunity to watch it live. Kasia Zalewska did an outstanding job of explaining some of the typical security vulnerabilities in embedded software, and what are some of the tools that can help mitigate them. I really loved the live demo part where she demonstrated a buffer overflow attack, as this really made it easier for me to understand how they can be conducted by an attacker, and how software can be hardened to detect/avoid them.

Update to TF-M 2.0

Trusted Firmware provides a reference implementation of secure software for Cortex-A (TF-A) and Cortex-M (TF-M). You can think of it as a toolbox that provides you with all the libraries and code you need to align with Arm’s latest recommendations and specifications regarding security. To quote the trustedfirmware.org website, “this forms the foundations of a Trusted Execution Environment (TEE) on application processors, or the Secure Processing Environment (SPE) of microcontrollers”.

Trusted Firmware-M v2.0.0 was released at the end of last year and one of the main highlights is its smaller memory footprint, in particular thanks to an update to mbedTLS 3.5.0.

As of this week, Zephyr supports TF-M 2.0.0! (PR #66288)

Socket service API

A new socket service has been introduced. It is somewhat similar to Linux’s inetd in that it allows to have only one thread that listens on a set of blocking sockets, and therefore save memory. When there is activity on one of the sockets, the service calls the appropriate callback (servlet? :)) to do the actual work.

A good starting point to learn more is to look at the newly introduced service-based echo server code sample. And of course, more details can also be found in the pull request, PR #66758.

Boards & SoCs

• The FK7B0M1-VBT6 board by FANKE Technology features an STM32H7B0VBT6 (Cortex-M7) running at up to 280 MHz, 128 KB of Flash (plus 2×8 MB external Flash), and 1.4 MB of SRAM. It can be sourced for about $30 on AliExpress, and is now supported in Zephyr! (PR #65441)

• I am always really excited to see new hardware from M5Stack supported in Zephyr. This week, it’s the M5Stack AtomS3 Lite It’s a device based on an ESP32S3 that’s about the size of a quarter, and that includes just about enough for simple prototyping: a push button, a few pins exposed through an expansion header, and even a mounting hole. (PR #67084)
• It’s great to see new options for using Bluetooth in Zephyr, this time with the X-NUCLEO-BNRG2A1 shield for STM32 boards. The shield uses a BlueNRG-M2SP application processor module based on the ST BlueNRG-2 System-on-Chip. (PR #67381)

SoC driver updates

• Voltage control support has been added to the Renesas PFC (pin fonction controller) driver. (PR #66881)
• New i.MX RGPIO (Rapid GPIO) driver. If you are using the NXP i.MX93 EVK board, it’s already been updated to use this new driver. (PR #62622)

General drivers

• The NXP DMIC (digital microphone) is a PDM-to-PCM converter intended for use with MEMS microphones. It supports up to 8 channels (or 4 L/R channel pairs) and now has a proper DMIC driver in Zephyr (nxp,dmic compatible). (PR #66448)
• The existing driver for the PCF8574 8-channel I/O expander has been reworked to now support PCF8575 as well, which is the 16-channel variant (new binding is nxp,pcf857x). (PR #67054)
• New UART shim for Nordic’s UARTE (UART with EasyDMA) driver. (PR #65155)
• When using cellular modems, handling of the AT+CESQ AT command for retrieving extending signal quality information has been implemented for U-blox SARA-R5 modem. (PR #67025)

Miscellaneous

• New DT_IRQ_INTC() and DT_IRQ_INTC_BY_NAME() macros allow to retrieve the interrupt controller associated to a given interrupt specifier Devicetree node. (PR #66707)
• New kernel APIs added to start and resume a CPU when running in an SMP environment: k_smp_cpu_start() and k_smp_cpu_resume(). (PR #64755)
• A new net_hostname_set() API allows to set the device hostname at runtime. (PR #67439)
• It is now possible to do runtime filtering of log messages (it used to be compile-time only) for a log frontend. (PR #67107)
• New net_buf_data_match() helper function to compare data with the contents of a network buffer. (PR #66757)
• Added support for SO_DOMAIN socket option. (#67618)
• New available POSIX APIs:
  • sched_getparam()
  • sched_getscheduler()

A big thank you to the 9 individuals who had their first pull request accepted this week, : @gzzi, @toonst, @laurin, @VitekST, @amrithvenkat, @shenyi97, @MirkoCovizzi, @mschappa, and @lopsided98.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

A new script to help you migrate boards to v2 model

Last week, I mentioned how Zephyr is transitioning to a new, better, model to describe SoCs and boards. To help with this transition, Gerard Marull has released a script that assists with migrating a group of boards to the new model. (PR #67423)

SBOM generation improvements

Thanks to PR #66182 by Thomas Gagneret, the modules that are composing a Zephyr application are now properly captured as actual packages when generating the SBOM (Software Bill of Materials) files.

##### Package: mbedtls

PackageName: mbedtls
SPDXID: SPDXRef-mbedtls-sources
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseInfoFromFiles: Apache-2.0
FilesAnalyzed: true
PackageVerificationCode: 53b2e7743712704ce9b05f8e17bc4eaba8776ddd

FileName: ./library/aes.c
SPDXID: SPDXRef-File-aes.c
FileChecksum: SHA1: ff7a9b66046c0de1a36bcd7c09a2307fb860aeb4
FileChecksum: SHA256: 5915d2544f3b93ed37f88a22b2d2e795447267119b553619231b75d83457679a
LicenseConcluded: Apache-2.0
LicenseInfoInFile: Apache-2.0
FileCopyrightText: NOASSERTION

...

As a reminder, generating the SBOM files for a Zephyr build, and therefore capturing the fingerprint of all the source files ending up in your application so that you can better assess if you’re impacted by software vulnerabilities further down the road, is something you can do in just a few lines.

New documentation pages

There’s been several substantial and most welcome additions made to the following areas of the documentation:

• A new network configuration guide walks you through the multiple Kconfig options that are available to you to configure your network stack, from buffers sizes to fine-tuning TCP options or configuring the TLS stack. Thank you Jukka for all the work on this one!
• Users of the CANbus subsystem will be happy to now have a complete reference for the can shell command. Thanks, Brix!
• Now that we have a gpio-kbd-matrix driver available, Fabio wrote a super detailed cheatsheet for all the various options it offers depending on the actual layout and wiring of your keyboards, and the hardware capabilities of your GPIO controller.
• In order to help navigate what kind of emulators/simulators are available to you, there is some great and steady progress being made to the Zephyr’s device emulators/simulators page, so I definitely encourage you to check it out to catch up on some of the things you probaby didn’t know existed

Boards & SoCs

• A new variant of the Panasonic PAN1783A, the PAN1783A-PA, has been added (PR #66620)
• The Seeed Studio LoRa-E5 mini from Seeed Studio is a LoRa devkit with a pretty small form factor, and based on STM32WLE5JC MCU. (PR #64279)
• The Kincony KC868-A32 board features 32 relays that can be used for home automation scenarios, as they’re rated for 220V/10A. What I find interesting with this board is that it has a Devicetree that can actually be an interesting reference for anyone interested in understanding how to configure an I/O expander (a PCF8574 in this particular case). (PR #66404)

SoC driver updates

• Support for FlexCAN added on NXP UCANS32K1SIC. (PR #67006)

General drivers

• Fabio describes it as the “last installment (maybe) of the general purpose input drivers” :), this week a new analog axis input driver has been added to allow to map values read on an ADC channel to changes on an input axis.
  The driver offers several configuration options such as calibrating min/max readings corresponding to the two ends of the axis, of course, but also setting a deadzone (don’t report changes when axis is mostly in the center of the range), etc. (PR #66600)
• Similar to the keyboard matrix driver, the gpio-keys driver can now be used in “polling” mode, in order to easily configure GPIO input keys even when the port doesn’t support interrupts (or you’re simply out of interrupts in your interrupt controller…). (PR #67208)
• A new driver zephyr,w1-gpio driver allows to use any GPIO as a 1-Wire master, using bit-banging. (PR #65948)
• The Bosch BMA4xx series of accelerometers is now supported. (PR #66242)
• A new driver has been added for controlling WS2812 LED strips on RP2040 (Raspberry Pi Pico), using the PIO (Programmable Input Output) framework. It’s really funny to see how concise PIO programs typically are. (PR #55226)
• MAX20355 regulator now supports “ship mode”, i.e. turning the PMIC off. (PR #67222)

Miscellaneous

• A new ztest shell command allows to run test suites and individual test cases directly from the Zephyr shell — neat! (PR #58374)
• A new riscv32_virtual board, emulated with Renode, can be used as an alternative to qemu for testing RISC-V 32 applications.
• Bluetooth Public Broadcast Profile (PBP) API and implementations are now available, allowing sources to allows sources to create a Public Broadcast Announcement, as well as parse Public Broadcast Announcements.
  The issue to add PBP support to Zephyr was opened over two years ago, so it is great to see this finally land! (PR #60777)
• Events related to access point mode are now exposed by the Wi-Fi manager, and you can better feedback on e.g. why an AP enable operation failed. (PR #67015)
• New available POSIX APIs:
  • sem_open(), sem_unlink() & sem_close()
  • sigprocmask()
  • clock_getcpuclockid()

A big thank you to the 11 individuals who had their first pull request accepted this week, : @andreeaDumitrache, @pamolloy, @ssnover, @RICCIARDI-Adrien, @jkandasa, @hcd-bdltd, @LukaszMadejGrinn, @walzsi, @Jonathan-Hamberg, @tgagneret-embedded, and @jzipperer-fb.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Happy New Year, everyone!

Working towards a new model for describing boards and SoCs

As Zephyr starts supporting more and more architectures, flavours of SoCs, and actual boards ; and as said boards become increasingly rich (e.g. it’s pretty common to find multiple SoCs on a single “board”), the way things are being described in the current Zephyr implementation is starting to show its limits. After several months of discussions and prototyping, a new way to describe SoCs and boards is being proposed.

I am really looking forward to how the new model will make adding a new SoC/board to Zephyr much easier (i.e. less files to touch), and how this will also enable better tooling, in particular from a documentation point of view (ex. quickly get a list of all the supported boards for a given SoC).

A new collaboration branch, collab-hwm, has been added to the Git repository, and you are invited to test things out and provide feedback. “v2” boards and SoCs are co-existing for now, but the goal will be that all existing ones eventually migrate to the new model.

Refreshing our Code of Conduct

It is worth mentioning that an update has recently been made to the project’s Code of Conduct.

Zephyr is using the Contributor Covenant as a template for its code of conduct, and the version we were using was several years old, and the recent update provides, among other things, improved guidelines regarding what may be the consequences for actions deemed in violation of the Code of Conduct.

Boards & SoCs

• The Adafruit QT PY RP2040 is a tiny board featuring a—you guessed it—RP2040 SoC, alongside an RGB NeoPixel, a USB connector, as well as a STEMMA QT connector. It is now supported in Zephyr thanks to PR #66603 and a first contribution from Ian Wakely (@raveious).

• Another Rasperry Pi Pico based board, the WIZnet’s W5500-EVB-Pico, was also introduced by Ian (PR #66523). It is basically your typical Raspberry Pi Pico, except that it’s coupled with the W5500 Ethernet MAC/PHY.
• Added support for Intel Raptor Lake CRB board (PR #66696).
• Added support for ST STM32H750B Discovery Kit (Arm Cortex-M7, 128K Flash, 1M SRAM). (PR #66280)

SoC driver updates

• ADC support has been added for Nuvoton numaker. (PR #66642)
• hwinfo driver added for Smartbond platforms, enabling access to the reset cause using the standard hwinfo_get_reset_cause() Zephyr API. (PR #64125)
• On ESP32, the Bluetooth driver now exposes the close() API, making it possible to properly close/disable the Bluetooth controller. (PR #66693)
• New clock controller driver for Raspberry Pi Pico. (PR #62186)
• BLE support using HCI has been added to ST STM32WBA SoC series (PR #66181). Worth noting that for now BLE is only compatible with the nucleo_wba55cg board.
• Added Ambiq HCI driver for Apollo4 Blue Plus. (PR #66227)
• Added support interrupt-driven UART mode for Renesas RA series. (PR #65775)

General drivers

• Initial support has been added for the popular DWC2 USB 2.0 controller. (PR #64943)
• New generic retained memory driver for retained registers (see zephyr,retained-reg compatible and PR #66992).
• New Cadence SDHC driver (PR #64036)

Input subsystem

• When running on the native simulator target, it is now possible to tap into the events generated by an evdev device on the host, and have them be automatically injected in your app as regular Zephyr input events.
  The documentation of the new zephyr,native-linux-evdev binding shows how simple it is to add one or more “evdev” nodes in your Devicetree, and later map them to actual evdev devices (as found in your /dev/input/ directory) when you run the application. (PR #66353)
• GPIO keys driver now properly supports power management. When suspended, all the button GPIOs and interrupts are disabled. (PR #66582)

Miscellaneous

• In order to automatically compute the minimal heap size that is (theoretically) needed for a given application to work, a new mechanism allows each subsystem to indicate how much heap size they need.
  The sum of each specified heap size requirement is then computed at build time (K_HEAP_MEM_POOL_SIZE), and used to actually set the size of the heap memory pool.
  The legacy CONFIG_HEAP_MEM_POOL_SIZE Kconfig may still be used but if it happens to be less than the computed K_HEAP_MEM_POOL_SIZE, the latter will be used and a build warning will inform you that the heap size you were trying to set manually is (theoretically at least) too small. If you know what you’re doing and want to force a manual override, you may set the Kconfig CONFIG_HEAP_MEM_POOL_IGNORE_MIN.
• New GDB stub available for AArch32 (only tested/available on Cortex-A for now). (PR #58067)
• Bluetooth Common Audio Profile (CAP) Commander discovery function has been implemented. (PR #64852)
• Bluetooth Mesh publications are now randomly delayed to better follow a recommendation in the specification. (PR ##66498)
• When using the net stats shell command to get statistics about an Ethernet interface, more details are now being output. (PR #66680)
• New available POSIX APIs:
  • pthread_getguardsize()
  • pthread_setguardsize()

A big thank you to the 19 individuals who had their first pull request accepted since the last post, : @tlissows, @raveious, @jrsa, @manuel-loew-infineon, @moonlight83340, @TomChang19, @gdb3-ampaworks, @TomasGalbickaNXP, @gumulka, @Manu3l0us, @Songjf-ttk, @rvoell-gcx, @Ryanjwoodward, @tomi-font, @Marquichou, @roymurlidhar, @javlands, @WilliamLeara, and @michal-smola.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Improved documentation search experience

One of the top complaints I’ve heard ever since I became the documentation manager for the Zephyr Project is how it can sometimes be hard to find information in the project’s documentation. It’s certainly true that the search engine historically available on docs.zephyrproject.org isn’t always giving the most helpful results.

As of last week, a new search experience is available with Google Programmable Search now being the default search engine when browsing the Zephyr documentation.

The new engine is faster, much more tolerant to typos, and allows you to write advanced search queries that are more than just a couple keywords (ex. you may use double-quotes to keep words together, exclude keywords by using the minus sign, etc.).

Meta-categories such as “Code Samples”, “API reference”, etc. are also available for you to narrow down the list of search results to only the category of results you care about (if you feel a category is missing, btw, let me know!). See for example the screenshot below, with top 3 results to the query “toggle a GPIO” — they are exactly what you’d expect them to be, but should you want more concrete examples of how to toggle a GPIO, clicking the “Samples” tab (or the green label in the search results) will give you just that!

Pro Tip: Press / to quickly focus on the search box while navigating the documentation.

Capacitive touch sensor for ESP32

Capacitive touch sensors are a kind of specialized GPIO with dedicated circuitry that detects an approaching finger by measuring a variation in the capacitance of the circuit.

Espressif devices typically include support for capacitive touch, and PR #64931 just made it possible to access this feature in Zephyr! The new driver is a standard input driver and as such fits nicely in the now pretty rich input subsystem.

The dedicated Devicetree binding, espressif,esp32-touch exposes a variety of settings to adjust the sensitivity, configure the debouncing, etc.

Here is, for example, the full Devicetree overlay to enable touch detection on pin TCH8 of my M5Stack AtomS3:

#include <zephyr/dt-bindings/input/input-event-codes.h>
#include <zephyr/dt-bindings/input/esp32-touch-sensor-input.h>

&touch {
	debounce-interval-ms = <30>;
	href-microvolt = <2700000>;
	lref-microvolt = <500000>;
	href-atten-microvolt = <1000000>;
	filter-mode = <ESP32_TOUCH_FILTER_MODE_IIR_16>;
	filter-debounce-cnt = <1>;
	filter-noise-thr = <ESP32_TOUCH_FILTER_NOISE_THR_4_8TH>;
	filter-jitter-step = <4>;
	filter-smooth-level = <ESP32_TOUCH_FILTER_SMOOTH_MODE_IIR_2>;

	status = "okay";

	touch_sensor_set: touch_sensor_0 {
		channel-num = <8>;
		channel-sens = <50>;
		zephyr,code = <INPUT_KEY_0>;
	};

};

And below is the code sample in action. If you’re not familiar with capacitive touch and a bit confused looking at the video, yes, this is indeed literally a single wire that’s being used as the input!

Funnily enough, it took me about 30 seconds to get the sample to work, and probably 10 times more to videotape it!

Boards & SoCs

• Beagleboard BeagleV-Fire is a single board computer (SBC) built around Microchip’s PolarFire MPFS025T SoC FPGA. In addition to providing an FPGA with 23K logic elements, it features a 5-core RISC-V 64-bit processor. (PR #66389)
• nRF9151-DK, an upcoming developer kit from Nordic Semiconductor and targeting DECT NR+ and LTE-M/NB-IoT with GNSS, is already supported in Zephyr . (PR #66110)
• The PAN1783A Evaluation Board from Panasonic is now supported. (PR #64259)
• The Ambiq Apollo4P evaluation board is built around Ambiq’s ultra-low power Apollo4 Plus SoC, which is a Cortex M4F @ 192 MHz. (PR #66328)
• ST Nucleo F722ZE is now supported. (PR #66050)

Drivers

• Expanding on the recently added modem subsystem, a new API has been added to interact with cellular modems in a consistent way across all available technologies (GSM, GPRS, LTE, etc.). Think retrieving signal strength information, for example.
  Check out the documentation here and how the new API is now used in the cellular modem code sample. (PR #65685)
• Ultrachip UC8175 support has been added. (PR #61439)
• The Charger API now includes a sbs_charger_charge_enable() standard API that can be use to initiate/terminate a charging cycle. (PR #66128)
• STM32 MCUs can now use SMBus thanks to the newly added driver. (PR #66260)
• New driver added for ST LIS2DU12 accelerometer. (PR #65734)

Miscellaneous

• The Bluetooth Gaming Audio Profile aims at enabling configuration of low-level audio services and profiles specifically for gaming use cases (ex. bidirectional voice for online chat, high bitrate for HQ game audio, etc.).
  PR #57032 is the oldest pull request merged this week (dating back to April of this year) and it introduces support for the Bluetooth Gaming Audio Profile in Zephyr.
• Initial support for USB Audio Class 2 has been added. The idea will be to allow developers to use the zephyr,uac2 binding to describe an USB Audio Class 2 device by utilizing the Devicetree vs. manually written code.
• A new API allows to configure CoAP retransmission settings. (PR #66025)
• Support for TCP Keep-Alive has been introduced and can be enabled using Kconfig option NET_TCP_KEEPALIVE. (PR #66316)
• The unused and obsolete arm_core_tz.c Arm TrustZone driver has been removed. (PR #66224)
• Improvements have been made to the Device Power Management framework to not unnecessarily resume/suspend in some situations. (PR #66246)
• If you’ve started to look into the new keyboard matrix driver, you will likely find the new input kbd_matrix_state_dump shell command quite useful. As its name indicates, given the id of a keyboard matrix Devicetree node, it will dump the state of the keyboard matrix every time a key is pressed/released.
• The documentation of the pytest plugin has been vastly improved, and so has the API reference for the Sockets API.

With the holiday season upon us, I will be back with the next update on January 5th. Hopefully I won’t be buried under thousands of pull requests to write about, but should that be the case I will do my best to highlight the most noteworthy ones!

A big thank you to the 12 individuals who had their first pull request accepted this week, : @ryukoposting, @hellesvik-nordic, @sebastianschlupp, @kevinior, @aofrioWeifengLi, @VuDangBP, @BryanZhuAM, @AlessioLei94, @alelec13, @helen741, @Burt-Silverman, and @sateeshkotapati.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

New emulated DMA driver

It is nice to see an increasing amount of emulated drivers added to Zephyr recently.

This week, a new zephyr,dma-emul binding was introduced. The associated driver provides a software implementation of a DMA controller that can be used to enable testing of areas and drivers otherwise difficult to test for they rely on DMA to be present.

See PR #58375 for more details.

Support for LVGL keypad input binding

Until PR #65002 being merged earlier this week, the LVGL keypad input device interface was the only input interface not yet supported in Zephyr (pointers, encoders, and buttons were already supported).

The new zephyr,lvgl-keypad-input binding allows to declare a new LVGL input device in your Devicetree that maps input codes (ex. INPUT_KEY_DOWN) coming from a Zephyr input device, to LVGL ones (ex. LV_KEY_NEXT).

The LVGL sample has been updated to support keypads, and is therefore now a neat showcase for all four LVGL input interfaces!

Networking

• Added support for setting multicast IPv4 TTL and IPv6 hop limit. (PR #65886)
• It is now possible to perform multicast join/leave operations through the standard BSD Sockets API. (PR #66018)
• A new fallback mechanism has been added to LwM2M subsystem.
  It is very common for a LwM2M client to have a list of several bootstrap server it may be trying to connecting to, so it only makes sense for the subsystem to support that and automatically try another bootstrap server from the configured list should connecting to the main one fail. Similarly, the fallback mechanism can be used for the connection to the actual LwM2M server, to switch to another one in case of lost connection. (PR #65745)
• The CoAP server now implements network management events. These can be quite convenient to be notified when e.g. a new observer is added/removed, or when the server start/stops.

Boards & SoCs

• Adafruit Grand Central M4 Express is a devkit based on the Microchip ATSAMD51, with 1MB flash, 256 KB RAM, and a whooping 70 GPIO pins in total! (PR #62618)
• STM32WBA55 SoC series is now supported, alongside the ST Nucleo WBA55CG board. Featuring both Arduino and STMorpho headers, and based on a Cortex-M33, this devkit aims at ultra low-power BLE applications. (PR #66073)

Drivers

• The keyboard matrix driver keeps getting nice improvements. It now supports polling and scan mode, to help in situations where one is not able to use interrupts for the GPIOs corresponding to the rows/columns.
  For example, large keyboard matrices might typically be accessed through a GPIO multiplexer that allows you to only “talk” to one row or column at a time.
  I am really looking forward to putting this new feature to use to add support for the M5Stack Cardputer and its cool keyboard
• Several fixes to Sierra Wireless HL7800 modem driver for better low-power support. (PR #66237)
• Added support for NTCG103JF103FT1 thermistor. (PR #62185)
• Quadrature decoder support has been added for NXP S32 series. (PR #65035)
• Added support for the ST LPS28DFW pressure sensor. (PR #65416).

Miscellaneous

• When using SNTP (Simple network time protocol), a new CONFIG_SNTP_UNCERTAINTY allows to get a more reliable timestamp. (PR #66233)
• When using Bluetooth Mesh, advertising is automatically suspended/resumed when enabling disabling Mesh. (PR #64721)
• OpenThread version has been updated, with added support for BLE TCAT (commissionning over BLE). (PR #66160)
• New POSIX API:
  • pthread_sigmask()

A big thank you to the 7 individuals who had their first pull request accepted this week, : @rabarar, @pillo79, @lukas-jung, @mikevoyt, @naNEQ, @jrhrsmit, and @TangleZ.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

• FOSDEM 2024, Feb. 3-4 in Brussels, Belgium—The CfP for the Embedded, Mobile and Automotive devroom closes a week from now, on December 8, so don’t wait to submit.
• Zephyr Developer Summit 2024 (co-located with Embedded Open Source Summit), Apr. 16-18 in Seattle, WA— You have a bit more time for this one, but make sure to not miss the January 14, 2024 deadline if you are interested in speaking at the event!

Also, a quick plug for the next Zephyr Tech Talk live stream on Wednesday, December 6 (note: we’ll be going live one hour later than our usual time, at 2pm GMT).

I will be chatting with open source rockstar Keith Packard about Picolibc, and how it can help you make your Zephyr application faster and leaner. I am very much looking forward to this one and hearing tons of C trivia from Keith

You can register here to make sure you get a reminder when we’ll go live, and you may of course consider spreading the word with your network, it’s always much appreciated!

Device multiplexing

There are many (maybe too many!) interesting tricks that can be implemented on top of Devicetree, and it gives a lot of flexibility in describing and tweaking the capabilities of your hardware.

This week, a new device multiplexer pseudo-device has been introduced. In a nutshell, this gives you a way to have a node in your Devicetree that acts as a proxy for other devices.

A typical application for this would be to be able to dynamically change which UART to use as the Zephyr console. Another interesting use case would be to have the devmux act as that one accel0 accelerometer sensor you’re using in your code, except that you could easily switch back and forth between an actual sensor, and an emulated one, for example. And all of this without having to continually update your Devicetree, recompile it, and run it again.

A picture being worth a thousands word, here’s a diagram that summarizes what’s going on under the hood.

            +----------+                            +----------+
            |  devmux  |                            |  devmux  |
            |          |                            |          |
 dev0       |          |                 dev0       |          |
 +---------->   \      |                 +---------->          |
            |    \     |                            |          |
 dev1       |     \    |       dev0      dev1       |          |       dev2
 +---------->      O   +---------->      +---------->      O   +---------->
            |          |                            |     /    |
 dev2       |          |                 dev2       |    /     |
 +---------->          |                 +---------->   /      |
            |          |                            |          |
            |          |                            |          |
            |          |                            |          |
            +-----^----+                            +-----^----+
                  |                                       |
   select == 0    |                       select == 2     |
   +--------------+                       +---------------+

From a Devicetree perspective, and for a use case where you’d want to multiplex multiple UARTs, it would look like the below:

/ {
    chosen {
        zephyr,console = &devmux0;
        zephyr,shell_uart = &devmux0;
    };

    &uart0 {
        status = "okay";
    };

    euart0: uart_emul0 {
        compatible = "zephyr,uart-emul";
        current-speed = <0>;
        status = "okay";
    };

    euart1: uart_emul1 {
        compatible = "zephyr,uart-emul";
        current-speed = <0>;
        status = "okay";
    };
};

Memory attributes based allocator

When configuring memory regions in the Devicetree, one can use the zephyr,memory-attr property to specify some flags that can then be used at runtime. This may be used for example by some drivers to indicate that they won’t function properly if used with specific types of memory, e.g. a DMA driver may require the use of non-cacheable memory.

A recently added feature makes it possible to fine-tune the way memory can be allocated from the heap, to help you easily get the right type of memory for your use case.

When CONFIG_MEM_ATTR_HEAP is set, all memory regions marked with specific flags (ex. DT_MEM_SW_ALLOC_CACHE) are added to a pool of memory heaps from which one can then allocate memory from by requesting chunks of memory of the desired type.

// Init the pool
mem_attr_heap_pool_init();

// Allocate 0x100 bytes of cacheable memory
block = mem_attr_heap_alloc(DT_MEM_SW_ALLOC_CACHE, 0x100);

// Allocate 0x200 bytes of non-cacheable memory aligned to 32 bytes
block = mem_attr_heap_aligned_alloc(ATTR_SW_ALLOC_NON_CACHE, 0x100, 32);

// Allocate 0x100 bytes of cacheable and dma-able memory
block = mem_attr_heap_alloc(DT_MEM_SW_ALLOC_CACHE | DT_MEM_SW_ALLOC_DMA, 0x100);

Adding support for recvmsg()

Zephyr’s BSD Sockets now implement proper support for the recvmsg() API.

As opposed to recv(), recvmsg() can be used with both connected (ex. TCP) and connection-less (ex. UDP) protocols to receive a message from an arbitrary network address.

When used alongside the IP_PKTINFO flag, it can also be useful to get additional information about an incoming packet, for example the address of the sender.

Check out PR #65694 for more details.

Boards & SoCs

• Arduino has gone a long way since its beginnings as a protyping tool for interaction design students. There is now a plethora of Arduino products very much geared towards industrial applications, and Arduino OPTA is one of them.
  Based on an STM32H747XI dual-core Arm® Cortex®-M7 +M4 MCU, it is basically a highly capable PLC (Programmable Logic Controller), that includes high-power relay switches, Modbus TCP and RTU capabilities, and more.
  As of this week and PR #64101, the M4 core of the Arduino OPTA is now officially supported in Zephyr!

• The NXP UCANS32K1SIC is a CAN signal improvement capability (SIC) evaluation board designed for both automotive and industrial applications that provides 2 CAN SIC interfaces and is based on a Cortex-M4F NXP S32K146 MCU. Now supported (PR #65461)
• The Renesas R-Car Spider board is the reference board for evaluating the Renesas R-Car S4 SoC family.
  Both the SoC and the board are now supported as of this week! (PR #56043)
• The Waveshare Pico UPS-B shield is a UPS (Uninterruptible Power supply) module designed for the Raspberry Pi Pico.
  It communicates with the Raspberry Pi Pico over I²C and allows to transparently control the charge of its battery and use it to power the Pi. It just joined the list of supported shields in Zephyr. (PR #60384)

Drivers

• The recently added GNSS subsystem gets a new generic NMEA driver, that can be used with any source of NMEA frames.
  When you really only care about getting and decoding the raw NMEA data straight from your GPS receiver, and have no interest in tinkering with the module’s settings (or maybe it doesn’t even have any), then this driver will be your new friend. (PR #65422)

&uart0 {
          current-speed = <9600>;
          ...
          gnss: gnss-nmea-generic {
                  compatible = "gnss-nmea-generic";
          };
  };

• I²C support added for Nuvoton Numaker. (PR #65673)
• Added support for NXP TJA1103 Ethernet PHY. (PR #65756)
• New experimental NXP ENET Ethernet driver. (PR #62833)

Miscellaneous

• I’ll have to dedicate a post to Zephyr’s Connection Manager at some point. In the meantime, very nice to see that the LwM2M code sample now puts it to good use, making it easier to try out LwM2M scenarios using a variety of connectivity options. (PR #65464)
• Added support for Bluetooth LE Power Control API. (PR #65273)
• Added support in LLEXT to load modules on Xtensa. (PR #62433)
• It is now possible to be notified when hostname gets updated, via a new NET_EVENT_HOSTNAME_CHANGED network management event. (PR #64093)
• New POSIX APIs:
  • pthread_cleanup_push() / pthread_cleanup_pop()
  • pthread_getconcurrency()
  • pthread_setcanceltype()

A big thank you to the 9 individuals who had their first pull request accepted this week, : @ShaharHD, @kilejin, @boz, @timwoolliscroft-opteran, @marcowidmer, @Grin00, @borrelunde, @arkwad, and @adamfc2000.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

Interestingly, by the end of the talk, I had shown most of the code on screen, all while digressing about many other things, answering questions, etc. I hope that helps make the point that Zephyr can really help you not reinvent the wheel, and help you focus more on the code that’s actually your application, and less on the boilerplate low-level stuff

Catch up on the recording here:

And as a reminder, all the code of the project is on GitHub, at so I encourage you to check it out!

And now, for the news from this past week…

Userspace on Xtensa

When building your application on top of Zephyr, you probably don’t want or need your entire code to run in supervisor mode, with full access to the memory, kernel objects, etc. While, say, a custom driver of your might require low-level interactions with the system, but your “actual” application probably only really cares about calling into a few APIs that will expose the data or functionality you need in your applications.

For architectures that include an MMU/MPU (Memory Management Unit / Memory Protection Unit), it is possible to instruct Zephyr to create so-called user-mode threads that end up running in their own sandbox, with very limited permissions unless explicitly granted.

This week, PR #61303 has introduced userspace support for Xtensa architectures, which is a major improvement, alongside a complete re-implementation of the MMU layer for Xtensa.

Picolibc 1.8.5

The newly released Zephyr SDK, version 0.16.4, ships the latest version of Picolibc, 1.8.5.

As per PR #62882, this new version of Picolibc brings more flexibility in selecting a printf/scanf variant to support only the format specifiers that one really needs, i.e. not bloat your binary if you don’t care about printing floats, for example.

As a reminder, while using a pre-compiled version from Picolibc straight from the SDK will give you faster compilation times, there is always the possibility to enable Kconfig option CONFIG_PICOLIBC_USE_MODULE if you want to tweak Picolibc further.

Stay tuned for a Zephyr Tech Talk entirely dedicated to Picolibc C on Wednesday, Dec. 6!

IGMPv3 support

The Internet Group Management Protocol (IGMP) is a protocol primarily used for managing multicast group memberships on IPv4 networks. It enables a host to inform its local router about its desire to join or leave a multicast group, which can be useful when building e.g. sensor networks where you want to use network resources as efficiently as possible.

As of this week, IGMPv3 is now supported. (PR #65293)

Among other things, IGMPv3 allows source filtering, enabling a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address.

Boards & SoCs

• STM32U5A9 SoC series is now supported, and the STM32U5A9J-DK development board has been added as well. (PR #64932)
• WeAct STM32G431 Core now supported (PR #63889)
• HelTec Wireless Stick Lite (V3), an ESP32-S3FN8-based devkit that features a Semtech SX1262 LoRa chip, is now supported. (PR #61930).
• Power Management support has been added for the STM32F4x chips. (PR #65050)

Drivers

• A new pwm-clock binding allows to add a clock control device for a PWM node, such that the PWM can be controlled using the clock control API.

pwmclock: pwmclock {
    status = "okay";
    compatible = "pwm-clock";
    #clock-cells = <1>;
    pwms = <&pwm_ccu40 2 PWM_HZ(1000000) PWM_POLARITY_NORMAL>;
};

• New regulator driver for Smartbond DA1469X SoC. (PR #65226)

Miscellaneous

• The Bluetooth Hearing Access (HAS) server now uses non-volatile settings to restore the client awareness of preset list entries exposed by the server. (PR #64164)
• A lot of work went into cleaning up the documentation of the POSIX API available in Zephyr.
• A new Kconfig option, CONFIG_SDL_DISPLAY_ZOOM_PCT allows to artificially tweak the scale of the main display when using a native simulation on your desktop.
  This can be really useful when testing, say, a 200x200px smartwatch GUI on your 32″ Retina display, without killing your eyes (PR #65556)
• New shell commands (that can be enabled using CONFIG_PLIC_SHELL) to display the hit count of each interrupt controller’s IRQ line. (PR #65533)

uart:~$ plic stats get interrupt-controller@c000000
   IRQ        Hits
==================
    10         236

uart:~$ plic stats clear interrupt-controller@c000000
Cleared stats of interrupt-controller@c000000.

uart:~$ plic stats get interrupt-controller@c000000
   IRQ        Hits
==================
    10          90

• Various improvements and optimizations to the modem UART backend (PR #65194)

A big thank you to the 12 individuals who had their first pull request accepted this week, : @ajarmouni-st, @lukas-fwdev, @adolfogc, @adleris, @arnaudmz, @adrienbruant, @wmrsouza, @falvia, @deveritec-rosc, @kamilrakoczy, @ndrs-pst, and @idruzhinin.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

I hope many of you will join, as I will be covering how I ended up migrating my now pretty old, and frankly quite hackish, Artificial Nose project to Zephyr in a matter of hours. I used this opportunity to deep more into some Zephyr features that I hadn’t add a chance to touch before, like Zbus, and I can’t wait to share my experience with y’all.

You should register to make sure you don’t miss the live stream, and of course feel free to also share the event with your network!

Support for C11 threads

The C11 standard introduced a native multi-threading API that aims at establishing a portable API for all things threads.

POSIX is of course a very popular programming model for manipulating threads, but being part of the language itself, the API introduced in the 2011 version of the C standard is effectively (or should be at least!) supported on *any* platform that supports the C11 standard.

#include <stdio.h>
#include <threads.h>

// Thread function
int printHelloWorld(void *arg) {
    printf("Hello, World!\n");
    return 0;
}

int main() {
    thrd_t thread;

    // Create a new thread
    if (thrd_create(&thread, printHelloWorld, NULL) != thrd_success) {
        fprintf(stderr, "Error creating thread\n");
        return 1;
    }

    // Wait for the created thread to terminate
    thrd_join(thread, NULL);

    return 0;
}

Chris Friedt has been working on bringing C11 threads support to Zephyr and this materialized this week with PR #60759 being merged. Quite interestingly, since Zephyr already exposes a POSIX API, most of the threads.h APIs end up mapping mostly 1-to-1 to POSIX functions.

Logging to multiple UARTs

A new zephyr,log-uart chosen node can be used to indicate that log outputs may be sent to multiple UARTs.

Until now, the UART log backend would have been only logging to the zephyr,console chosen node, but with PR #64917 it’s now possible to have the following kind of node in your Devicetree to indicate the various UARTs where you’d like logs to show up:

/ {
	chosen {
		zephyr,log-uart = &log_uarts;
	};

	log_uarts: log_uarts {
		compatible = "zephyr,log-uart";
		uarts = <&uart0 &uart1>;
	};

    ...
};

New keyboard matrix GPIO driver

A new type of driver has been introduced to allow modeling a keyboard matrix out of any set of GPIOs. The gpio-kbd-matrix binding allows you to define your keyboard matrix configuration such as:

  kbd-matrix {
          compatible = "gpio-kbd-matrix";
          row-gpios = <&gpio0 0 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>,
                      <&gpio0 1 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
          col-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>,
                      <&gpio0 3 GPIO_ACTIVE_LOW>,
                      <&gpio0 4 GPIO_ACTIVE_LOW>;
          no-ghostkey-check;
  };

More details in PR #65117.

Boards & SoCs

• The nRF9131 Evaluation Kit from Nordic is a single-board evaluation kit for the nRF9131 SiP for LTE-M and NB-IoT.

• The M5Stack AtomS3 is a *very* tiny ESP32-S3 based developer kit that manages to fit a small 0.85″ LCD display on what is effectively a 1×1″ (24×24mm) piece of electronics!
  Since it also has an on-board accelerometer, it can run the LVGL Accelerometer Chart code sample out-of-the-box!

• The Renesas Starter Kit+ for RZ/T2M is an evaluation and development kit for the RZ/T2M MPU. (PR #64566)
• Support has been added for the Verdin iMX8M Plus Computer on Module (CoM) from Toradex. (PR #61713)
• UP Squared Pro 7000 is now supported. It is the 3rd generation of palm-sized developer board of UP Boards series and it is powered by an Intel Alder Lake N (Intel N-series Platform) SoC. (PR #65019)
• Support has been added for the STM32H7B0 SoC series. (PR #65092)

Drivers

• New driver for the Linear Technologies LTC2451 ADC, an ultra-tiny 16-bit ADC. (PR #64390)
• New driver for Renesas HS3001 and HS3003 temperature/humidity sensors (PR #63016)
• A charger driver has been added to the already existing regulator driver for the MAX20335 multi-function device. (PR #64971)
• The LPS22DF altimeter / pressure sensor is now supported. It is an ultracompact, piezoresistive, absolute pressure sensor that can be used as a digital output barometer, with an output data rate up to 200 Hz (PR #62028)
• The NXP LPC DMA driver now supports hardware triggering. (PR #64573)
• New driver for NXP FlexRAM memory controller. FlexRAM is a highly configurable and flexible RAM memory array, found on e.g. RT10XX and RT11XX series. (PR #62788)
• New modem driver for Quectel EG25-G. (PR #64746)
• New driver for ExplorIR-M CO2 sensor. A new co2_polling code samples was also introduced to make it easy to try things out with this driver (or any other CO2 driver really!). (PR #64621)
• A new CAN shell command (can timing) adds support for setting raw timing values. (PR #65054)

Miscellaneous

• The inter-core messaging (ICMsg) backend now supports the transfer of dynamically allocated buffers. (PR #58741)
• Added API to BLE Audio CAP to set codec capabilities. (PR #63223)
• Zephyr native simulator is now the recommended target for running Zephyr in your desktop/POSIX environment, and the documentation has been updated to reflect that.
• The UART Shell backend has been reworked to support the asynchronous UART API. (PR #63967)
• A new set of shell commands (cred ...) allow to interactively set TLS network credentials. See the list of commands here. (PR #64343)
• MCUmgr OS management group now has functions for getting/setting the current time to/from the rtc alias device. (PR #64934)
• The Bluetooth “broadcast audio source” code sample now supports using e.g. your host computer as the audio source.
  Granted that you are running the sample on a device that has a USB Device stack and Audio support, enabling CONFIG_USE_USB_AUDIO_INPUT will make your device show up as a sound device when plugged to your computer, and any audio that you will send to this “virtual speaker”, will be broadcast over LE Audio!

A big thank you to the 11 individuals who had their first pull request accepted this week, : @TimTTP, @GabrielHAFs, @LipinskiPNordicSemi, @michael-whg, @josuah, @CkovMk, @CharlesDias, @ndaneil, @xvigo, @KamilxPaszkiet, and @mpenate-ellenbytech.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update:

This survey is very helpful in shedding some light on the technology stacks people are using in their IoT solutions, and it’s nice to see Zephyr is on their radar.

In other news, here are some of the things that have kept the Zephyr community busy this week!

CoAP “servlets”

When building an IoT device, one typically wants to spend time writing their actual application logic, not reinventing the wheel regarding how they should implement the “Internet” aspect of their “Thing”

A merged pull request from this week, PR #64265, is introducing a CoAP server API that allows to easily register CoAP resources against a CoAP “service”, effectively getting rid of most of the boilerplate one would have to come up with if building on lower layer APIs.

In a nutshell, and in a slightly simplified way, a minimal CoAP server + /hello resource would not require much more code than:

COAP_SERVICE_DEFINE(coap_server, 
			"0.0.0.0",
			&coap_port, 
			COAP_SERVICE_AUTOSTART);

static int my_get(struct coap_resource *resource, struct coap_packet *request,
                  struct sockaddr *addr, socklen_t addr_len)
{
    static const char *msg = "Hello, world!";
    uint8_t data[CONFIG_COAP_SERVER_MESSAGE_SIZE];
    struct coap_packet response;
    
    /** ... **/
    
    coap_packet_append_payload(&response, (uint8_t *)msg, sizeof(msg));

    return coap_resource_send(resource, &response, addr, addr_len);
}


static const char * const my_resource_path[] = { "hello", NULL };
COAP_RESOURCE_DEFINE(my_resource, coap_server, {
    .path = my_resource_path,
    .get = my_get
});

The CoAP service can then be started/stopped using coap_service_start()/coap_service_stop() (in the example above it’s set to start automatically) or using shell commands, and things like the magic ./well-known/core endpoint, retransmissions, etc. are automatically taken care of by the service.

I love it when Zephyr gets new features like this. This new service feels very much like what you would expect to find in a full-blown operating system, and yet we’re still talking about super constrained devices here.

You should definitely check out the code sample to get more familiar with this new API.

Boards & SoCs

• Arm Cortex-A and Cortex-R now support SMP! It is worth noting that FPU_SHARING and USERSPACE are not supported yet. (PR #61206)
• It is now possible to have a custom interrupt control interface implementation on Cortex-M, using the CONFIG_ARM_CUSTOM_INTERRUPT_CONTROLLER option.
  While all Cortex-M platforms have an NVIC controller,custom SoCs may have additional IRQ controllers, or require custom handling. This option allows to indicate that these SoCs are using custom interrupt control interface implementation
• The Firefly ROC-RK3568 mini computer is an ARM64 board with a quad-core Cortex-A55 @ 2GHz, 4GB of LPDDR, 32GB of eMMC, M.2 PCI Express slots, dual Gigabit Ethernet ports, and more. It is now supported in Zephyr! (PR #64217)

• Support has been added for the Lolin S2 Mini (also known as Wemos S2 Mini …and I am realizing as I am typing this that I have one sitting on my desk, and one connected to my electricity meter monitoring the consumption of my house! Guess I need to do some hacking and porting soon!). This small devkit features an ESP32-S2 with 4MB of Flash, 2MB of PSRAM, and can be used with a variety of shields.
• On STM32, the ADC driver now supports power management. A code sample has been added to demonstrate the improvements (spoiler alert: consumption can be almost 20x less now). (PR #64191)
• Clock control driver is now available for Ambiq SoCs. (PR #63097)
• Added support for NXP Multirate Timer peripheral. (PR #64801)

Drivers

• A new Wi-Fi driver is available for the Infineon AIROC, as found in CYW4343W, CYW4373, CYW43012, CYW43012, CYW43439. It is pretty exciting since among other things, it means we should soon see Wi-Fi support added to the Rasperry Pi Pico W. (PR #63721)
  • The already supported CY8CPROTO-062-4343W board now has Wi-Fi functionality enabled.
• The aforementioned Wi-Fi module supports both SPI and SDIO interfaces, and it’s the latter that’s used by the driver for now.
  SDIO is an extension of the SD specification covering I/O functions, and it turns out support for it was also just added to Zephyr. (PR #56869)
• The Analog AD5592 is a versatile multifunction IC that has 8 I/O pins that can be independently configured to act as DAC output, ADC inputs, or regular GPIOs.
  A new “multi-function” driver is now available to leverage all these different options easily from the Devicetree. (PR #64592)
• New Ethernet driver for Microchip LAN8651. (PR #63614)
• New driver for the TSL2561 light sensor. (PR #56869)

Miscellaneous

• A new spinlock mechanism, ticket spinlocks, has been introduced. It is meant to help in situations where traditional locking would be “unfair” across multiple CPUs due to how the implementation only relies on a single atomic variable. Ticket spinlocks provide true FIFO ordering at the cost of slightly increased memory footprint. (PR #61541)
• Some awesome work to implement the official LwM2M interoperability tests, in particular the ones related to bootstrapping, registration, device management and service enablement interface, and information reporting interface. I highly encourage you to have a look as this is also a great way to get up to speed with using Pytest for Zephyr testing 🙂 (PR #64013)
  
  I wonder if the Open Mobile Alliance still organizes PlugFests, but I would live to see Zephyr participate in the future.
• CMSIS version has been updated to 5.9.0 in the Zephyr manifest. (PR #64851)
• API for Bluetooth CAP Commander has been introduced. (PR #64645)

A big thank you to the 7 individuals who had their first pull request accepted this week, 💙 🙌: @cocoeoli, @mgolu, @topisani, @samueltardieu, @p9n, @BenjaminDeuter, and @raffi-g.

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

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.

Catch up on all previous issues of the Zephyr Weekly Update: