Happy Friday! Another week, another round of new features, drivers, and more. Before jumping into the actual news, I want to mention that I will soon be launching a recurring series of Virtual Zephyr Talks. These will be video interviews and presentations with guests from the embedded and IoT community at large, where we will discuss best practices, tech news, and maybe more importantly answer all the questions you may have, live!
I encourage everyone to subscribe to the Zephyr YouTube channel, if you haven’t already, as this will allow you to not miss upcoming notifications and live streams when we go live with this in the next few weeks. Also, if you are reading this and feel like you would have something cool to show off during an upcoming episode, please shoot me a message!
AWS IoT Core Sample
Lucas Dietrich contributed a comprehensive code sample that demonstrates how to publish messages to AWS IoT Core from a Zephyr application using the MQTT protocol. It includes key concepts such as establishing a TLS 1.2 connection, subscribing to a topic, and of course publishing data.
“This sample can be used as a starting point for developers who are interested in building their own IoT solutions using Zephyr RTOS and AWS IoT Core.”
Lucas Dietrich
Head over to the sample documentation page to get all the info you need to run it on your own device! 🙂
New boards, shields & SOCs
- The PSoC™ 6 BLE Prototyping Board is a low-cost development board for designing and debugging solutions based on the PSoC 6 MCU from Infineon Technologies. As you can see in the picture, the PCB is split in two halves — you can just snap away the programmer and debugger module from the main board as you’re getting to the final stages of your prototyping phase!
PR #56169 added the board definition to Zephyr, with lots of on-board features being supported out-of-the-box, including of course Bluetooth.
- NXP’s RT1040 EVK is now supported in Zephyr! This devkit comes with the i.MX RT1040 MCU (Cortex-M7, 600 MHz), 256MB of RAM, 64MB of QSPI Flash, Ethernet, a CAN transceiver, …
- The board definition for NXP i.MX8’s Audio DSP core has been updated (PR #57084) and now supports UART.
- The board definition for NXP MIMXRT1010-EVK evaluation kit now contains a description of its Arduino headers making it easier to use Arduino shields more transparently, i.e. you can simply mount the shield’s sensors and peripherals on
arduino_i2corarduino_spiand they will just work (PR #57433). - Single-threading support has been added for the RISC-V architecture (PR #53346). When in single threaded mode, only the main thread is enabled and as such, Zephyr will look for a
main()function to execute. - GDMA (General Direct Memory Access) support has been added for ESP32S3 SoCs (PR #57495). GDMA is a feature that allows peripheral-to-memory, memory-to-peripheral, and memory-to-memory data transfer at a high speed. The CPU is not involved in the GDMA transfer, and therefore it becomes more efficient with less workload.
Drivers
I really enjoy keeping an eye on the changes on the sensor driver front, as it is a good opportunity to learn about potentially lesser known types of sensors, so I’m glad this week has been pretty active for all things drivers!
IMU Sensors
- The BMI323 from Bosch Sensortec is an IMU (Inertial Measurement Unit) that provide acceleration and angular rate measurement. It can be used for motion detection, fitness tracking, … Bjarki added support for it this week via PR #56594, and it features lots of Zephyr goodness.
One thing that I particularly like is that the driver leverage’s Zephyr power management capabilities to allow the sensor to achieve the lowest possible power consumption until it’s effectively resumed. - Another IMU sensor to join the hundreds of already supported ones is the LSM6DSO16IS from STMicroElectronics. The interesting thing with this one is its ISPU (Intelligent Sensor Processing Unit) which allows to run advanced signal processing and AI algorithms right on the sensor. The sensor can also act as a sensor hub for sensor fusion scenarios, and it can collect data from up to 4 external sensors attached to it.
The new driver supports fetching accelerometer and gyroscope data, as well as fetching data from the “companion” sensors that may be connected to the hub.
Display
- Support has been added for the SSD1680 electronic paper display chip (commit #daf9030f).
- Related: the generic SSD16xx display driver has seen a significant improvement that now allows to get much better control on partial refreshes (PR #48163). Board and shields featuring e-ink displays have been updated to use the newly added refresh profiles.
ADC
- The recently added driver for Texas Instruments ADS114S0x ADC now allows access to the port expander (PR #55789).
- ADC driver has been added for the i.MX 6SoloX Processors (PR #40355).
- As part of ongoing housekeeping efforts, the ADC driver for STM32 has been updated to allow setting sampling time directly through the Devicetree (PR #57342).
Others
- OpenTitan is an open source silicon Root of Trust (RoT) project that uses the LowRISC RISC-V core. A driver for OpenTitan SPI host has been added (PR #54639).
- The driver for NOR Octo-SPI flash on STM32 has been improved to wait for the erase operation to complete before returning (PR #56472). This fixes potential issues when one would try to access the chip while a (typically long) erase operation was still in progress.
- An initial version of Infineon CAT1 flash driver has been contributed (PR #56667).
Wi-Fi
- One of the Wi-Fi power saving features consists in advertising a listening interval (“I will be sleeping–to save power–and only waking up every X beacon intervals. #kthxbai”). Thanks to PR #57116, the Wi-Fi API and shell commands make it possible to configure the “Listen Interval” power save mode
- It is now possible to access raw Wi-Fi scan data. The
wifi scanshell command has also been updated to output the raw scan data should the feature be enabled (PR #57699). - If you are using Wi-Fi on ESP32, you will be interested in learning that you can now use the
wifi scanandwifi statusshell commands, thanks to the fix in PR #57627.
USB
- The USB Battery Charging (BC) v1.2 specification defines limits and detection mechanisms for USB devices to draw current exceeding the USB 2.0 specification limit of 0.5A, 2.5W.
Support for allowing BC1.2 peripherals to act as a charging device–a capability often provided on USB Type-C ports–has been added to Zephyr with PR #57101). - USB Communications Device Class (CDC) Ethernet Control Model (ECM) class has been added to the new experimental USB device support.
The USB CDC-ECM specification allows devices to use a USB interface to emulate an Ethernet network connection. In simpler terms, it allows a device to connect to a network (like the internet) through a USB connection instead of a traditional network cable. See PR #54448.
Miscellaneous
- Several notable Bluetooth bug fixes:
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:
