Tag: zephyr-weekly-update

There’s no such thing as summer holidays for the Zephyr community, it would seem. It’s very nice to see ACPI support being introduced this week, and there’s also intereting work being done on making it easier and more flexible to run Zephyr applications natively on your development machine.

This week, I would also like to point out the Github issues that are explicitly labelled as “good first issues”. I am highlighting some of these in the article below, but generally speaking I would really encourage you to regularly check them out, as your first contribution to Zephyr might be lying there 🙂 Also, if you’re a maintainer, a kind reminder that there are probably many issues opened in your area of expertise that could be good ones for newcomers, so don’t forget to tag them as part of bug triaging!

ACPI Support

One of the biggest changes this week is the addition of initial support for the ACPI (Advanced Configuration and Power Interface) standard.

The ACPI standard has been around for over 25 years and provide a hardware abstraction layer to help with power management, auto configuration, and status monitoring of peripherals.

The new implementation is using the ACPICA open source project, and allows to discover and configure hardware components at run-time, perform power management (e.g. putting unused hardware components to sleep), and perform auto configuration tasks. You can check out the documentation of the new ACPI API here. (PR #56347)

Native simulator

Another significant change is the introduction of a new “virtual” board to be used for simulation purposes, the native simulator, a.k.a. native_sim. (PR #59302)

You may be already familiar with the native_posix which allows you to run Zephyr natively on e.g. your local Linux machine. It’s very complete, and allows to go as far as simulating a display, a real-time clock, etc. which is very handy in situation where you don’t need (or sometimes can’t) test against real hardware.

This new “native simulator” is meant to make it easier to run against a custom libC (where native_posix would typically use the host’s libC). It also makes it possible to simulate assymetric multiprocessing scenarios (several simulated MCUs, each running their own Zephyr instance).

SoCs

• Support has been added for STM32L451 SoC series from STMicroelectronics. (PR #59763)
• PR #58332 added support for the NXP MR-CANHUBK3 (see below), but also worth noting that it also brought support for the entire NXP S32K344 SoC family, a series of qualified MCUs based on the Arm Cortex-M7 and aimed at safety-critical automotive and industrial applications.

Boards & shields

• A new board from Seeed Studio has been added, the XIAO ESP32S3 (PR #59732). It is built around Espressif’s 240MHz Xtensa 32-bit LX7 dual-core processor, and supportsWiFi and BLE 5.0. And it’s super tiny!
  I am really excited about this one since this board also has a “Sense” variant that comes with a 1600x1200px camera, a micro-SD card reader, and a digital microphone, for only a few dollars more. In fact, since the initial contribution did not include the XIAO ESP32S3 Sense variant, I would love for someone to contribute it! In fact, I just opened an issue to track this, and I would recommend you look into it as your first potential contribution to Zephyr 😉

• The NXP MR-CANHUBK3 board is an evaluation board for mobile robotics applications (ex. autonomous mobile robots and automated guided vehicles for which support was added this week. (PR #58332)

• All the STM32 Nucleo-64 boards from STMicroelectronics feature a Morpho connector—think of it as an Arduino connector on steroids, as it has more pins and allows to access all the I/Os of the MCU.
  PR #59754 adds the nexus node definitions for the 15 Nucleo-64 kits supported in Zephyr, making it easier to directly manipulate the Morpho pin headers (for example ST_MORPHO_CN7_25 on the NUCLEO-L476RG would be equivalent to pin 14 on GPIO port C).

• The Arduino click shield from MIKROE can be stacked on any Arduino compatible board and exposes two mikroBUS sockets, that can be used to connect any of the hundreds (!) of Click boards available from MIKROE. It is now supported in Zephyr and exposes the two mikroBUS headers. (PR #60009)

Drivers

• New driver for Texas Instruments TLA2021, a cost-optimized, ultra-small, 12-Bit ADC typically used for system-monitoring applications (ex. battery voltage supervision, current sensing, …). (PR #57861)
• Flash SPI NOR driver now supports device power management. (PR #59647)
• New counter driver for Renesas SmartBond general purpose timers. (PR #56758)

Bluetooth

• Kconfig options for Bluetooth Mesh have been reorganized to be easier to manipulate. Among other things, options are now grouped according to the protocol layer (network, transport, etc.) they are related to. (PR #59909)
• A new optional module allows to collect statistics related to mesh frames. It can be helpful for measuring performance, packet loss, etc. The module can be turned on via BT_MESH_STATISTIC Kconfig option. It also comes with shell commands to help access the statistics interactively. (PR #59962)
• A new shell module has been added for TMAP (Telephony and Media Audio Profile). (PR #58915)

Miscellaneous

• Our documentation website docs.zephyrproject.org provides seamless integration of Doxygen documentation in the general documentation pages. This used to be provided by the breathe Python library, but as of this week we’ve switched to using docleaf, an improved and faster alternative to the former, made by its original author. One of the biggest improvement is around incremental builds, as rebuilding the documentation when only a few things have been changed is now much faster! Thanks Michael for this awesome first contribution to the project!
• A lot of work is being done on the POSIX front to get to a point where the PSE52 profile is fully supported for the upcoming LTS v3 release. There are dozens of open issues flagged as “Good First Issues” that I encourage you to look at if you’d like to contribute to Zephyr but don’t know where to start. Plus, you will likely learn a few things about threads, semaphores, and more! 🙂

A big thank you to the 14 individuals who had their first pull request accepted this week, 💙 🙌: @najumon1980, @robertoxmed, @mku514k, @jaiiarora, @andy9a9, @Maxwelltoo, @michaeljones, @jasperjonker, @EricNRS, @bperseghetti, @Chenhongren, @faloj, @MrMarteng, and @ithinuel.

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 previous issues of the Zephyr Weekly Update:

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: