Categories
IoT Zephyr

Zephyr Weekly Update – zspdx is getting some love

The Zephyr community is definitely back to full-speed after the short holiday break, and I feel like I really need to re-think the format of these weekly updates so that I can be more efficient in putting them together, while still providing you with more insights than what you’d get from just looking at the git log! Anyways, that’s an implementation detail, and you’re probably here for this week’s update, and not for reading my random thoughts 🙂

A new script to help you migrate boards to v2 model

Last week, I mentioned how Zephyr is transitioning to a new, better, model to describe SoCs and boards. To help with this transition, Gerard Marull has released a script that assists with migrating a group of boards to the new model. (PR #67423)

SBOM generation improvements

Thanks to PR #66182 by Thomas Gagneret, the modules that are composing a Zephyr application are now properly captured as actual packages when generating the SBOM (Software Bill of Materials) files.

##### Package: mbedtls

PackageName: mbedtls
SPDXID: SPDXRef-mbedtls-sources
PackageDownloadLocation: NOASSERTION
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseInfoFromFiles: Apache-2.0
FilesAnalyzed: true
PackageVerificationCode: 53b2e7743712704ce9b05f8e17bc4eaba8776ddd

FileName: ./library/aes.c
SPDXID: SPDXRef-File-aes.c
FileChecksum: SHA1: ff7a9b66046c0de1a36bcd7c09a2307fb860aeb4
FileChecksum: SHA256: 5915d2544f3b93ed37f88a22b2d2e795447267119b553619231b75d83457679a
LicenseConcluded: Apache-2.0
LicenseInfoInFile: Apache-2.0
FileCopyrightText: NOASSERTION

...

As a reminder, generating the SBOM files for a Zephyr build, and therefore capturing the fingerprint of all the source files ending up in your application so that you can better assess if you’re impacted by software vulnerabilities further down the road, is something you can do in just a few lines.

New documentation pages

There’s been several substantial and most welcome additions made to the following areas of the documentation:

  • A new network configuration guide walks you through the multiple Kconfig options that are available to you to configure your network stack, from buffers sizes to fine-tuning TCP options or configuring the TLS stack. Thank you Jukka for all the work on this one!
  • Users of the CANbus subsystem will be happy to now have a complete reference for the can shell command. Thanks, Brix!
  • Now that we have a gpio-kbd-matrix driver available, Fabio wrote a super detailed cheatsheet for all the various options it offers depending on the actual layout and wiring of your keyboards, and the hardware capabilities of your GPIO controller.
  • In order to help navigate what kind of emulators/simulators are available to you, there is some great and steady progress being made to the Zephyr’s device emulators/simulators page, so I definitely encourage you to check it out to catch up on some of the things you probaby didn’t know existed 🙂

Boards & SoCs

  • A new variant of the Panasonic PAN1783A, the PAN1783A-PA, has been added (PR #66620)
  • The Seeed Studio LoRa-E5 mini from Seeed Studio is a LoRa devkit with a pretty small form factor, and based on STM32WLE5JC MCU. (PR #64279)
  • The Kincony KC868-A32 board features 32 relays that can be used for home automation scenarios, as they’re rated for 220V/10A. What I find interesting with this board is that it has a Devicetree that can actually be an interesting reference for anyone interested in understanding how to configure an I/O expander (a PCF8574 in this particular case). (PR #66404)

SoC driver updates

  • Support for FlexCAN added on NXP UCANS32K1SIC. (PR #67006)

General drivers

  • Fabio describes it as the “last installment (maybe) of the general purpose input drivers” :), this week a new analog axis input driver has been added to allow to map values read on an ADC channel to changes on an input axis.
    The driver offers several configuration options such as calibrating min/max readings corresponding to the two ends of the axis, of course, but also setting a deadzone (don’t report changes when axis is mostly in the center of the range), etc. (PR #66600)
  • Similar to the keyboard matrix driver, the gpio-keys driver can now be used in “polling” mode, in order to easily configure GPIO input keys even when the port doesn’t support interrupts (or you’re simply out of interrupts in your interrupt controller…). (PR #67208)
  • A new driver zephyr,w1-gpio driver allows to use any GPIO as a 1-Wire master, using bit-banging. (PR #65948)
  • The Bosch BMA4xx series of accelerometers is now supported. (PR #66242)
  • A new driver has been added for controlling WS2812 LED strips on RP2040 (Raspberry Pi Pico), using the PIO (Programmable Input Output) framework. It’s really funny to see how concise PIO programs typically are. (PR #55226)
  • MAX20355 regulator now supports “ship mode”, i.e. turning the PMIC off. (PR #67222)

Miscellaneous

  • A new ztest shell command allows to run test suites and individual test cases directly from the Zephyr shell — neat! (PR #58374)
  • A new riscv32_virtual board, emulated with Renode, can be used as an alternative to qemu for testing RISC-V 32 applications.
  • Bluetooth Public Broadcast Profile (PBP) API and implementations are now available, allowing sources to allows sources to create a Public Broadcast Announcement, as well as parse Public Broadcast Announcements.
    The issue to add PBP support to Zephyr was opened over two years ago, so it is great to see this finally land! (PR #60777)
  • Events related to access point mode are now exposed by the Wi-Fi manager, and you can better feedback on e.g. why an AP enable operation failed. (PR #67015)
  • New available POSIX APIs:
    • sem_open(), sem_unlink() & sem_close()
    • sigprocmask()
    • clock_getcpuclockid()

A big thank you to the 11 individuals who had their first pull request accepted this week, 💙 🙌: @andreeaDumitrache, @pamolloy, @ssnover, @RICCIARDI-Adrien, @jkandasa, @hcd-bdltd, @LukaszMadejGrinn, @walzsi, @Jonathan-Hamberg, @tgagneret-embedded, and @jzipperer-fb.

As always, I very much welcome your thoughts and feedback in the comments below!

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:

Categories
IoT Zephyr

Zephyr Weekly Update – Kicking off 2024!

Happy New Year, everyone! 🎆 Before jumping into everything that happened in Zephyr land over the holiday break, I want to remind everyone that the deadline to submit a talk to Zephyr Developer Summit 2024 will be approaching really fast. You have until Sunday, January 14 to propose a talk, so don’t wait too long!

Working towards a new model for describing boards and SoCs

As Zephyr starts supporting more and more architectures, flavours of SoCs, and actual boards ; and as said boards become increasingly rich (e.g. it’s pretty common to find multiple SoCs on a single “board”), the way things are being described in the current Zephyr implementation is starting to show its limits. After several months of discussions and prototyping, a new way to describe SoCs and boards is being proposed.

I am really looking forward to how the new model will make adding a new SoC/board to Zephyr much easier (i.e. less files to touch), and how this will also enable better tooling, in particular from a documentation point of view (ex. quickly get a list of all the supported boards for a given SoC).

A new collaboration branch, collab-hwm, has been added to the Git repository, and you are invited to test things out and provide feedback. “v2” boards and SoCs are co-existing for now, but the goal will be that all existing ones eventually migrate to the new model.

Refreshing our Code of Conduct

It is worth mentioning that an update has recently been made to the project’s Code of Conduct.

Zephyr is using the Contributor Covenant as a template for its code of conduct, and the version we were using was several years old, and the recent update provides, among other things, improved guidelines regarding what may be the consequences for actions deemed in violation of the Code of Conduct.

Boards & SoCs

  • The Adafruit QT PY RP2040 is a tiny board featuring a—you guessed it—RP2040 SoC, alongside an RGB NeoPixel, a USB connector, as well as a STEMMA QT connector. It is now supported in Zephyr thanks to PR #66603 and a first contribution from Ian Wakely (@raveious).
WIZnet W5500-EVB-Pico

SoC driver updates

  • ADC support has been added for Nuvoton numaker. (PR #66642)
  • hwinfo driver added for Smartbond platforms, enabling access to the reset cause using the standard hwinfo_get_reset_cause() Zephyr API. (PR #64125)
  • On ESP32, the Bluetooth driver now exposes the close() API, making it possible to properly close/disable the Bluetooth controller. (PR #66693)
  • New clock controller driver for Raspberry Pi Pico. (PR #62186)
  • BLE support using HCI has been added to ST STM32WBA SoC series (PR #66181). Worth noting that for now BLE is only compatible with the nucleo_wba55cg board.
  • Added Ambiq HCI driver for Apollo4 Blue Plus. (PR #66227)
  • Added support interrupt-driven UART mode for Renesas RA series. (PR #65775)

General drivers

  • Initial support has been added for the popular DWC2 USB 2.0 controller. (PR #64943)
  • New generic retained memory driver for retained registers (see zephyr,retained-reg compatible and PR #66992).
  • New Cadence SDHC driver (PR #64036)

Input subsystem

  • When running on the native simulator target, it is now possible to tap into the events generated by an evdev device on the host, and have them be automatically injected in your app as regular Zephyr input events.
    The documentation of the new zephyr,native-linux-evdev binding shows how simple it is to add one or more “evdev” nodes in your Devicetree, and later map them to actual evdev devices (as found in your /dev/input/ directory) when you run the application. (PR #66353)
  • GPIO keys driver now properly supports power management. When suspended, all the button GPIOs and interrupts are disabled. (PR #66582)

Miscellaneous

  • In order to automatically compute the minimal heap size that is (theoretically) needed for a given application to work, a new mechanism allows each subsystem to indicate how much heap size they need.
    The sum of each specified heap size requirement is then computed at build time (K_HEAP_MEM_POOL_SIZE), and used to actually set the size of the heap memory pool.
    The legacy CONFIG_HEAP_MEM_POOL_SIZE Kconfig may still be used but if it happens to be less than the computed K_HEAP_MEM_POOL_SIZE, the latter will be used and a build warning will inform you that the heap size you were trying to set manually is (theoretically at least) too small. If you know what you’re doing and want to force a manual override, you may set the Kconfig CONFIG_HEAP_MEM_POOL_IGNORE_MIN.
  • New GDB stub available for AArch32 (only tested/available on Cortex-A for now). (PR #58067)
  • Bluetooth Common Audio Profile (CAP) Commander discovery function has been implemented. (PR #64852)
  • Bluetooth Mesh publications are now randomly delayed to better follow a recommendation in the specification. (PR ##66498)
  • When using the net stats shell command to get statistics about an Ethernet interface, more details are now being output. (PR #66680)
  • New available POSIX APIs:
    • pthread_getguardsize()
    • pthread_setguardsize()

A big thank you to the 19 individuals who had their first pull request accepted since the last post, 💙 🙌: @tlissows, @raveious, @jrsa, @manuel-loew-infineon, @moonlight83340, @TomChang19, @gdb3-ampaworks, @TomasGalbickaNXP, @gumulka, @Manu3l0us, @Songjf-ttk, @rvoell-gcx, @Ryanjwoodward, @tomi-font, @Marquichou, @roymurlidhar, @javlands, @WilliamLeara, and @michal-smola.

As always, I very much welcome your thoughts and feedback in the comments below!

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:

Categories
IoT Zephyr

Zephyr Weekly Update – Fixing the search experience

As a lot of folks are wrapping up for the holiday season, the Zephyr community hasn’t slowed down all that much last week and there were quite a few noteworthy additions that this blog post will be covering, including a pretty cool (albeit short!) demo video.

Improved documentation search experience

One of the top complaints I’ve heard ever since I became the documentation manager for the Zephyr Project is how it can sometimes be hard to find information in the project’s documentation. It’s certainly true that the search engine historically available on docs.zephyrproject.org isn’t always giving the most helpful results.

As of last week, a new search experience is available with Google Programmable Search now being the default search engine when browsing the Zephyr documentation.

The new engine is faster, much more tolerant to typos, and allows you to write advanced search queries that are more than just a couple keywords (ex. you may use double-quotes to keep words together, exclude keywords by using the minus sign, etc.).

Meta-categories such as “Code Samples”, “API reference”, etc. are also available for you to narrow down the list of search results to only the category of results you care about (if you feel a category is missing, btw, let me know!). See for example the screenshot below, with top 3 results to the query “toggle a GPIO” — they are exactly what you’d expect them to be, but should you want more concrete examples of how to toggle a GPIO, clicking the “Samples” tab (or the green label in the search results) will give you just that!

Search results for “toggle a GPIO” using the new search experience in docs.zephyrproject.org

💡 Pro Tip: Press / to quickly focus on the search box while navigating the documentation.

Capacitive touch sensor for ESP32

Capacitive touch sensors are a kind of specialized GPIO with dedicated circuitry that detects an approaching finger by measuring a variation in the capacitance of the circuit.

Espressif devices typically include support for capacitive touch, and PR #64931 just made it possible to access this feature in Zephyr! The new driver is a standard input driver and as such fits nicely in the now pretty rich input subsystem.

The dedicated Devicetree binding, espressif,esp32-touch exposes a variety of settings to adjust the sensitivity, configure the debouncing, etc.

Here is, for example, the full Devicetree overlay to enable touch detection on pin TCH8 of my M5Stack AtomS3:

#include <zephyr/dt-bindings/input/input-event-codes.h>
#include <zephyr/dt-bindings/input/esp32-touch-sensor-input.h>

&touch {
debounce-interval-ms = <30>;
href-microvolt = <2700000>;
lref-microvolt = <500000>;
href-atten-microvolt = <1000000>;
filter-mode = <ESP32_TOUCH_FILTER_MODE_IIR_16>;
filter-debounce-cnt = <1>;
filter-noise-thr = <ESP32_TOUCH_FILTER_NOISE_THR_4_8TH>;
filter-jitter-step = <4>;
filter-smooth-level = <ESP32_TOUCH_FILTER_SMOOTH_MODE_IIR_2>;

status = "okay";

touch_sensor_set: touch_sensor_0 {
channel-num = <8>;
channel-sens = <50>;
zephyr,code = <INPUT_KEY_0>;
};

};

And below is the code sample in action. If you’re not familiar with capacitive touch and a bit confused looking at the video, yes, this is indeed literally a single wire that’s being used as the input!

Funnily enough, it took me about 30 seconds to get the sample to work, and probably 10 times more to videotape it! 😝

Boards & SoCs

BeagleBoard BeagleV®-Fire
  • Beagleboard BeagleV-Fire is a single board computer (SBC) built around Microchip’s PolarFire MPFS025T SoC FPGA. In addition to providing an FPGA with 23K logic elements, it features a 5-core RISC-V 64-bit processor. (PR #66389)
  • nRF9151-DK, an upcoming developer kit from Nordic Semiconductor and targeting DECT NR+ and LTE-M/NB-IoT with GNSS, is already supported in Zephyr 🙃. (PR #66110)
  • The PAN1783A Evaluation Board from Panasonic is now supported. (PR #64259)
  • The Ambiq Apollo4P evaluation board is built around Ambiq’s ultra-low power Apollo4 Plus SoC, which is a Cortex M4F @ 192 MHz. (PR #66328)
  • ST Nucleo F722ZE is now supported. (PR #66050)

Drivers

  • Expanding on the recently added modem subsystem, a new API has been added to interact with cellular modems in a consistent way across all available technologies (GSM, GPRS, LTE, etc.). Think retrieving signal strength information, for example.
    Check out the documentation here and how the new API is now used in the cellular modem code sample. (PR #65685)
  • Ultrachip UC8175 support has been added. (PR #61439)
  • The Charger API now includes a sbs_charger_charge_enable() standard API that can be use to initiate/terminate a charging cycle. (PR #66128)
  • STM32 MCUs can now use SMBus thanks to the newly added driver. (PR #66260)
  • New driver added for ST LIS2DU12 accelerometer. (PR #65734)

Miscellaneous

  • The Bluetooth Gaming Audio Profile aims at enabling configuration of low-level audio services and profiles specifically for gaming use cases (ex. bidirectional voice for online chat, high bitrate for HQ game audio, etc.).
    PR #57032 is the oldest pull request merged this week (dating back to April of this year) and it introduces support for the Bluetooth Gaming Audio Profile in Zephyr.
  • Initial support for USB Audio Class 2 has been added. The idea will be to allow developers to use the zephyr,uac2 binding to describe an USB Audio Class 2 device by utilizing the Devicetree vs. manually written code.
  • A new API allows to configure CoAP retransmission settings. (PR #66025)
  • Support for TCP Keep-Alive has been introduced and can be enabled using Kconfig option NET_TCP_KEEPALIVE. (PR #66316)
  • The unused and obsolete arm_core_tz.c Arm TrustZone driver has been removed. (PR #66224)
  • Improvements have been made to the Device Power Management framework to not unnecessarily resume/suspend in some situations. (PR #66246)
  • If you’ve started to look into the new keyboard matrix driver, you will likely find the new input kbd_matrix_state_dump shell command quite useful. As its name indicates, given the id of a keyboard matrix Devicetree node, it will dump the state of the keyboard matrix every time a key is pressed/released.
  • The documentation of the pytest plugin has been vastly improved, and so has the API reference for the Sockets API.

With the holiday season upon us, I will be back with the next update on January 5th. Hopefully I won’t be buried under thousands of pull requests to write about, but should that be the case I will do my best to highlight the most noteworthy ones!


A big thank you to the 12 individuals who had their first pull request accepted this week, 💙 🙌: @ryukoposting, @hellesvik-nordic, @sebastianschlupp, @kevinior, @aofrioWeifengLi, @VuDangBP, @BryanZhuAM, @AlessioLei94, @alelec13, @helen741, @Burt-Silverman, and @sateeshkotapati.

As always, I very much welcome your thoughts and feedback in the comments below!

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: