Zephyr Weekly Update – I’m sensing some improvements!

Zephyr 3.4 was released last week, so new features started to flow again into the main repository for the upcoming 3.5 version of Zephyr, which is due in just about 4 months. The most notable change from this week is the addition of a new sensing subsystem, which provides a higher level of abstraction to interact with sensors and orchestrate/consolidate the data they expose (sensor fusion).

Next week, the Zephyr community will gather in Prague for the Zephyr Developer Summit (the agenda is packed!), and I hope to see many of you there!

New sensing subsystem

The new Sensing Subsystem is a high-level sensor framework which you can think of as a conductor for an “orchestra” of sensors.

Often times, your high-level application will not (want to) be responsible for directly interacting with a sensor hardware, and will just want to know about the sensor data itself (plus metadata, too, such as timestamps, units, …), which it can now get from the sensing subsystem rather than by requesting it using the underlying, lower level, Sensor API. The sensing subsystem is responsible for orchestrating efficient polling of sensor data (if two “consumers” need temperature data at a time interval of 1sec, surely there’s no need to have them both read virtually the same data from the sensor), and can also centralize/rationalize things such as power management.

What’s more, it makes it super easy to come up with virtual sensors, that are not directly bound to physical hardware / drivers, but rather consume and process data from other (physical) sensors to expose “virtual” sensor streams to applications. For example, a virtual podometer sensor could take data from a gyroscope and an accelerometer sensor, and turn it into a sensor exposing step count data that any app could use just as if it were any other type of physical sensor. Of course, this also enables sensor fusion scenarios, where the same gyroscope and accelerometer could be consolidated into a virtual 6-DOF IMU.

Sensor fusion is the process of combining sensor data or data derived from disparate sources such that the resulting information has less uncertainty than would be possible when these sources were used individually.

Wikipedia

This new subsystem is 100% optional. In particular, if your app only needs to access “simple” sensors, you should probably keep directly using the Zephyr Sensors API.

Architecture overview of the new Zephyr sensing subsystem.

See the main documentation page already linked above, and PR #55389 for more details. There’s a couple of additional pull requests already lined up that will enrich the subsystem in the coming weeks.

SoCs

Nuvoton NuMicro M46x series of MCUs is now supported. These Cortex-M4F based MCUs (up to 200MHz / 512K SRAM / 1M Flash) are targeted for IoT gateway, industrial control, telecom and data center applications (PR #55406)
Intel FPGA Nios V/g General Purpose Processor is now supported (PR #59043).
Core dump is now supported on ESP32-S2 and ESP32-S3 (PR #58738)
On RISC-V processors, Physical Memory Protection (PMP) provides a way to enforce access permissions to certain ranges of addresses in memory. PR #58379 leverages PMP to detect null pointer exceptions: a protected region is set around address 0x0 so that null pointer de-referencing effectively triggers a CPU exception that can be “nicely” reported as an access fault.

Boards & shields

The NuMaker PFM M467 is an IoT development board built around the NuMicro® M467 MCU whose support was added this week. (PR #55406)
Together with the addition of the Nios V/g General Purpose Processor, the Intel FPGA Design Store Nios® V/g Hello World Example Design system is now a supported “board” too. It contains the following IP blocks (remember, this is an FPGA): the processor itself, a JTAG UART, and on-chip memory.

Drivers

Texas Instruments LP5569 is a 9-channel I2C RGB LED driver. It can be programmed with lighting patterns that can be applied to each LED without involving the main MCU (think, “breathing” pattern on smart home devices).
PR #58179 adds a driver for the LP5569 (note that the “autonomous” lighting patterns thing I just described is not part of the driver), allowing to control each of the 9 LED on/off/brightness state. A code sample has also been added for making it even easier to get started with this driver.
Texas Instruments ADS1112 is a 16-bit ADC than can perform conversions at rates up to 240 samples per second.
It’s aimed at applications that require high-resolution measurements, ex. portable instrumentation, industrial process control, etc. PR #56826 added support for this IC, and one can use the ADC shell commands to quickly interact with it.
The nPM1300 PMIC from Nordic Semiconductor can control up to 3 LEDs, either in an automatic fashion (ex. based on charging status, presence of charging cable or not, etc.) or through software. PR #58352 adds the LED driver in Zephyr.
- As you may remember from previous posts, and just like many other PMICs out there, the nPM1300 can do *many* things (voltage regulator, battery gauge, control GPIOs, …) so it’s worth noting that there’s now a proper MFD (multi-fonction device) driver for it, thanks to PR #58478.

Bosch BMM150 is a low-power, low-noise, 3-axis magnetometer. PR #58857 adds proper support for power management (which makes sense, as it’s meant to be a low-power sensor ).
The UART driver for ESP32-S3 now supports asyncronous mode (PR #58737).
The PS/2 driver for Microchip now supports low-power mode and wakeup (PR #56991).

Miscellaneous

Bluetooth Mesh now supports virtual addresses. Virtual addresses are more or less “labels” that can be assigned to one or more nodes in a mesh network. (PR #57878)
The Devicetree binding for the Global Interrupt Controller (GIC) on Arm now allows to specify the GIC version (v1, v2, v3), and doing it through KConfig CONFIC_GIC_VX option is deprecated. The goal is to leverage better Devicetree as an actual way to describe the hardware as completely and accurately as possible. (PR #58035).
For regulators that support DVS (Dynamic Voltage Scaling), there is now a shell command (regulator dvsset) that allows to set a regulator’s DVS state (PR #58873).