Category: IoT

Happy Friday, from sunny Prague, Czech Republic! As hundreds of Zephyr users, contributors, and maintainers gathered in-person (and virtually too!) this week, this Friday’s digest is a bit on the light side. Indeed, most of the “cool” stuff this week probably happened anywhere but in the GitHub repository: from the face-to-face meeting of the project’s Technical Steering Committee, to the dozens of talks at the Zephyr Developer Summit, and the numerous impromptu chats in-between sessions. That being said, there’s definitely a bunch of updates that are worth highlighting, so please keep reading 🙂

Before moving on to the digest, I wanted to make sure to call out the catalog of products running Zephyr that’s featured on the Zephyr Project’s website, as there’s been a few very interesting additions to it recently.

Did you know that Vestas wind turbines are effectively powered by Zephyr? Oh, and wind too, I guess 🙃 but then Zephyr is also the god of the West wind, is it not?

If you are building a product using Zephyr, I would strongly recommend you consider getting it added to the catalog. This is an opportunity to make your product and company more visible, but also a great way to support the project by showing the breadth of use cases and applications that Zephyr is suited for.

Just fill out the dedicated form, and get your product added!

And now, for this week’s update!

Boards & shields

• The Titanium Ti60 F225 Development Kit from Efinix is a development kit built around the Ti60 FPGA (a 225-ball FineLine BGA package fabricated on a 16nm process) with 256 Mb of HyperRAM on board. Efinix propose a RISC-V based soft-core for this board/FPGA, for which support has just been added to Zephyr. (PR #56370)

• NXP RT1170 EVKB is a new revision to the popular RT1170 Evaluation Kit. It has an audio connector and an additional display connector compared to the previous revision, and is now supported upstream. (PR #59212)

Connectivity

Several interesting fixes and improvements this week on the Wi-Fi, CoAP, and LWM2M fronts:

• Zephyr’s CoAP Client can now handle multiple concurrent requests (PR #59757).
• Support for X509 certificates has been added in the LWM2M client, in addition to pre-shared keys (PSK) that were already supported. (PR #59019).
• Wi-Fi passive scanning allows to passively wait for advertisement frames on each channel as opposed to actively probing the network. It can therefore be more power efficient.
  PR #59204 makes it possible to use passive mode when scanning a network, and also provides a way to make passive scan the default mode.
• net_if_is_wifi() API has been added to the Network Interface abstraction layer and allows to check whether a given interface supports Wi-Fi.

Drivers

• When using an ADC (Analog to Digital Converter) to measure the output of a current sensing circuit, you’re reading volts, which is not necessarily helpful since you probably care more about the actual current going through your sense resistors, and not the output voltage.
  There are now two new bindings available for current sensing circuits (current sense shunts and current sense amplifiers) that essentially allows you to transparently manipulate actual current reading as opposed to “raw” voltage information. Combined with some now current_sense_ API and macros, it is now possible to describe the circuit in your Devicetree (ex. set the shunt resistor value, or the amplifier gain), and then directly and transparently convert ADC readings (in volts), to the current value (in amps) measured by the circuit. Handy! ⚡️

• Code has also been added to allow you to do something similar for voltage dividers, so that you can easily calculate the “scaled” output when using the voltage divider binding. As voltage dividers are slightly easier to grasp for my electronics-newbie brain, let me try and explain in a bit more detailed why I find this really cool and handy.
  Basically, you can describe the values of the Z1 and Z2 resistances in your circuit in your Devicetree, and indicate which ADC I/O channel you’re going to get the “raw” readings from. Once that is done, you can then use voltage_divider_scale_dt() in your code (and pass it a static initializer for your voltage divider node, ex. sensor0 in the example below) to directly have the ADC reading converted to the “original” scaled voltage, in just one line. With the divider configuration below, should the ADC input be 1.000V, the scaled output would in fact be 2.000V). Didn’t I say handy? 🙂 ⚡️

	sensor0: vd {
		compatible = "voltage-divider";
		io-channels = <&adc0 0>;
		output-ohms = <50>;
		full-ohms = <100>;
	};

• The ICM42688 (3-axis gyroscope and a 3-axis accelerometer MEMS sensor from TDK) now has an async API. (PR #58870)
• A driver has been added for the I2C controller on the PolarFire SoC Icycle kit (PR #59101).
• A watchdog driver has been added for Andes atcwdt200 as found on e.g. AndeShape AE350 platform (PR #59258).

Miscellaneous

• A useful fix in Zephyr’s JSON parser for properly handling multidimensional arrays (PR #50816).
• The implementation of the POSIX stat() function has been fixed and will now correctly return informations about the file such as file size, etc. (thanks to @plinnie for their first contribution to Zephyr, with PR #59278!).

A big thank you to the 4 individuals who had their first pull request accepted this week, 💙 🙌: @Cladoc, @ethan-duckett-brill, @mkettn, and @plinnie.

As always please feel free to jump in with your thoughts or questions in the comments below. See you next week!

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

Catch up on all the editions of the Zephyr Weekly Update:

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.

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

A big thank you to the 15 individuals who had their first pull request accepted this week, 💙 🙌: @cyliangtw, @donatieng, @MSEEHenrik, @supperthomas, @reportingsjr, @Nicolas62x, @jmontgomery-cruise, @ZYNQHRONIZE, @MarkoSagadin, @p-woj, @tenllado, @msmttchr, @ghu0510, @zapol, and @trustngotech.

As always please feel free to jump in with your thoughts or questions in the comments below. See you next week!

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

Catch up on all the editions of the Zephyr Weekly Update:

Another short update this week… or maybe not? … drumroll … Zephyr 3.4 has just been released, and I invite everyone to check out the two resources below to learn all about it!

In this blog post on the Zephyr website, I’ve cover some of the highlights of the release. I have also asked Anas and Joshua, our two release engineers for Zephyr 3.4, to share what their favorite thing about the release is.

The following video (which turned out to be slightly longer than I had originally intended, for there was just so much to cover!) will be a good watch if you want to see some of the new features in action.

Also, please make sure to check out the full release notes to get an even more accurate view of all the API changes, etc.

I am terrified at the perspective of resuming the normal course of the weekly updates next week, now that the floodgates will open and all the pull requests towards Zephyr 3.5 that have lined up during the 3.4 feature freeze will start getting merged 😉 But this should make for a packed update next week, eh?

Also, last call to everyone who’d like to attend Zephyr Developer Summit / Embedded Open Source Summit at the end of the month. I think there might still be a few tickets available to attend in person, but you may also consider virtual attendance too! You can register here.

As always please feel free to jump in with your thoughts or questions in the comments below. See you next week!

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

Catch up on all the editions of the Zephyr Weekly Update: