Apologies for missing last week’s update. Last Friday was the feature freeze for Zephyr 3.5 and everyone, including myself, was pretty busy trying to push everything over the finish line!
Because of the feature freeze, no significant changes happened in the last week, so this update will still pretty much feel like a “weekly”, I guess 🙂 I will try to keep it short (…ish) since I am preparing a full write-up about what’s new in Zephyr 3.5, and I don’t want to spoil all the fun! I would also like to apologize to the Bluetooth contributors and maintainers in particular as I’m pretty sure I am missing important stuff — I definitely spotted lots of stabilization and bug fixing but if I forgot something important, please let me know in the comments or on Discord!
Also, remember to join Peter and me next Wednesday, Oct. 11, for our 3rd Zephyr Tech Talk, where we’ll discuss everything you need to know about Renode! I’d actually recommend you “RSVP” on LinkedIn, as this is the best way to make sure you will get a reminder as we go live. You can also of course spread the word in your network, if you feel like it.
Linkable loadable extensions (llext)
The newly introduced Linkable Loadable Extensions (llext) subsystem makes it possible to dynamically extend the functionality of an application at runtime. Extensions can be loaded from pre-compiled ELF formatted data which is verified, loaded, and linked with other extensions.
As often, an example is worth a thousand words and I encourage you to use the llext shell commands to get a feel of what it’s all about. A dedicated sample will give you all the instructions you need to build a “Hello World” binary, and then dynamically load it and invoke it using shell commands (there is even a command to load the hex-encoded binary, so you can actually do the whole thing without leaving your Zephyr shell!).
uart:~$ llext help
llext - Loadable extension commands
Subcommands:
list :List loaded extensions and their size in memory
load_hex :Load an elf file encoded in hex directly from the shell input.
Syntax:
<ext_name> <ext_hex_string>
unload :Unload an extension by name. Syntax:
<ext_name>
list_symbols :List extension symbols. Syntax:
<ext_name>
call_fn :Call extension function with prototype void fn(void). Syntax:
<ext_name> <function_name>
I am really excited about what’s going to come next now that one of the most requested feature since many years is basically unlocked. There’s still a lot that needs to be done (as an example, in this initial version, one may need to disable memory protection for llext to work…) but that makes things even more exciting! (PR #57086)
Binary descriptors
Binary descriptors are a new feature that makes it super simple to describe data objects (think: “model number” of your device, “kernel version”, etc.) that end up being linked at a known offset in your binary.
Like I just said, binary descriptors are really easy to use:
#include <zephyr/bindesc.h>
BINDESC_STR_DEFINE(app_version, BINDESC_ID_APP_VERSION_STRING, "1.2.3");
“Standard” binary descriptors such as build time, or kernel version, can be enabled without having to change anything in your code, just by enabling the dedicating Kconfig options.
A new west bindesc command has been introduced to allow developers to read binary descriptors in .bin, .hex, .elf, or .uf2 binary files.
You may want to check out the new code sample to familiarize yourself with the different macros and tools surrounding binary descriptors.
(PR #54464)
Object cores
Object cores are a new kernel debugging tool that can be used to both identify and perform operations on registered objects.
Kernel objects such as semaphores, message queues, etc. may now (if enabled via the dedicated CONFIG_OBJ_CORE_ * Kconfig options) embed a new “object core” that can be used to gather and access all sorts of statistics about the object.
The documentation page for this new feature is quite frankly excellent, so I would recommend you check it out as it’s gonna do a better job than I ever will at explaining things!
(PR #59075)
Boards & SoCs
- As everyone is talking about the Raspberry Pi 5 these days, this will likely not get all the attention it deserves, but did you know that Zephyr now supports Raspberry Pi 4 Model B?
It is very early stage and very few peripherals are supported at the moment, but the idea of being able to run Zephyr on an MPU board that many people already have handy is very cool. And it’s always nice to see new Arm64 SoCs and boards being added!
(PR #62320). - Support for Nucleo U5A5ZJ-Q was added. As a reminder the U5 series features Arm® Cortex®-M33 cadenced at up to 160 MHz, and the “U” stands for ultra low-power 🙂 (PR #63144)
Drivers
- Added TMAG5170 3d Hall effect sensor driver. It is a pretty complete driver with power management, CRC-based error detection, trigger mode, … so you may want to bookmark it for next time you need to write a sensor driver! (PR #61346)
- New HM330X particle sensor driver. I actually wrote this driver as it’s a sensor that I’ve been using to monitor dust levels in my pottery studio. It’s proven to be very accurate and reliable even when running 24/7 which, to be honest, is not always the case for “cheap” maker-oriented sensors. I think it might have been my first sensor driver contribution to the project, and I have to admit it went pretty smoothly! (PR #62786)
- New Microchip CAN-FD MCP251xFD driver, “an important addition to the existing range of Zephyr CAN drivers” to quote Brix, one of the maintainer of the CAN subsytem. (PR #59968)
- New DMA driver for NXP SMARTDMA. This IP is is a custom peripheral intended for graphics acceleration on the NXP RT595 (PR #57616)
- STM32 I2C driver now supports 10-bit addressing (PR #60620)
- RTC driver for STM32 now supports sub-second ticks (note that this increases power consumption). (PR #61580)
- New PWM pulse capture driver for S32K344. (PR #62695)
- Added eDMA support for S32K344. (PR #61311)
- New bit-bang driver for MDIO. (PR #56679)
- New ALTERA Parallel I/O (PIO) driver. It supports calibration, setting/getting alarms, and alarm callbacks. (PR #61162)
- New Ambiq AM1805 RTC driver. (PR #62357)
- Support has been added for Intel eMMC host controller. (PR #61108)
- New vertical decoder API for decoding sensor data. (PR #61022)
adc_read_dt()function to read from an ADC by providing a Devicetree node . (PR #63010)
Miscellaneous
- When using MCUboot, the Kconfig option
CONFIG_MCUBOOT_BOOTLOADER_NO_DOWNGRADEallows an application to know whether downgrade prevention is enabled. (PR #63053) - New Bluetooth code sample for HCI UART using the Async API. (PR #59880)
- LwM2M client now supports CoAP blockwise transfer for GET and FETCH operations. (PR #61858)
- New ICMP API to allow applications to send and receive IPv4 or IPv6 ICMP Echo Request messages. (PR #62942)
- The obsolete neural_net driver and experimental Gaussian & Neural Accelerator API have been removed. (PR #62796 and #63300)
- You can now test the WebUSB code sample directly from the Zephyr documentation. (PR #62420)
A big thank you to the 21 individuals who had their first pull request accepted in the past 2 weeks, 💙 🙌: @moritzstoetter, @ivaniushkov, @fkwasowi, @nik012003, @meshium, @jandriea, @hlord2000, @wouterh, @srisurya1, @JeroenReeskamp, @bjda, @Fladdan, @zohavas, @lifenggitacc, @dcorbeil, @stasys0, @AirChandler, @lindblandro, @graffiti, @rahul-sin, and @tbr-tt.
As always, I very much welcome your thoughts and feedback in the comments below. See you in two weeks, as I don’t think next week will see any noteworthy update as the final release approaches.
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:
