Category: IoT

I hope everyone had a great week! After a pretty massive heat wave in Southern Europe this week, it’s time to put together this week’s recap of Zephyr news. Not an awful lot, but some pretty cool topics nevertheless! As always please feel free to yell at me if you feel I forgot something important!

Zephyr docs get a major speed boost!

Recent tweaks in the configuration of the Zephyr documentation server are making it up to 5x faster.

This should make for a huge boost in your overall user experience when browsing the documentation, especially if your Internet connection speed is a bit average. Please let me know in the comments if it’s making an improvement for you, and feel free to share other feedback regarding the documentation in general!

Enhanced Wi-Fi management capabilities

The Wi-Fi management API now provides the ability to perform advanced scanning operations, for example to only scan on a particular band and/or channel range. The best way to start tinkering with the newly added functionalities is probably to use the wifi scan shell command. (PR #60686)

 Scan for Wi-Fi APs

    [-t, --type <active/passive>] : Preferred mode of scan. The actual mode of scan can depend on factors such as the Wi-Fi chip implementation, regulatory domain restrictions. Default type is active.
    [-b, --bands <Comma separated list of band values (2/5/6)>] : Bands to be scanned where 2: 2.4 GHz, 5: 5 GHz, 6: 6 GHz.
    [-a, --dwell_time_active <val_in_ms>] : Active scan dwell time (in ms) on a channel. Range 5 ms to 1000 ms.
    [-p, --dwell_time_passive <val_in_ms>] : Passive scan dwell time (in ms) on a channel. Range 10 ms to 1000 ms.
    [-s, --ssids <Comma separate list of SSIDs>] : SSID list to scan for.
    [-m, --max_bss <val>] : Maximum BSSes to scan for. Range 1 - 65535.
    [-c, --chans <Comma separated list of channel ranges>] : Channels to be scanned. The channels must be specified in the form band1:chan1,chan2_band2:chan3,..etc. band1, band2 must be valid band values and chan1, chan2, chan3 must be specified as a list of comma separated values where each value is either a single channel or a channel range specified as chan_start-chan_end. Each band channel set has to be separated by a _. For example, a valid channel specification can be 2:1,6-11,14_5:36,149-165,44
    [-h, --help] : Print out the help for the scan command.

Boards & SoCs

• A new ESP32S3-based developer kit is supported, the ESP32S3-CORE from LuatOS. My Chinese knowledge being more than limited, I don’t have a lot of details on this board, but LuatOS is apparently an open source project aimed at enabling Lua on constrained devices (16K RAM, 128K Flash). I don’t know if the LuatOS framework runs Zephyr under the hood, but I guess it’s now a possibility on the ESP32S3-CORE at least!

Drivers

• If you are using the fuel gauge driver API, it now has support for battery cutoff (PR #61435). The main application for this functionality (also referred to as ship mode or shelf mode) is to help reduce battery drain while devices are stored.
• The driver for nPM1300 PMIC now supports trigger mode. This is particularly useful to treat events such as “battery removed”, or “charge completed” as actual interrupts in your system. (PR #60677)
• The newly added regulator-gpio driver introduces basic support for controlling a regulator using GPIOs (ex. 1 pin sets output voltage to X, another pin sets it Y, and another pin allows to enable/disable it). The documentation for the regulator-gpio binding actually does a great job of explaining the concept. (PR #58411)
• On NXP S32 boards, the GPIO driver now allows you to use the pin_get_config() and port_get_direction() APIs. (PR #61590)

A big thank you to the 8 individuals who had their first pull request accepted this week, 💙 🙌: @bene42, @nguyenmthien, @butok, @danielstuart14, @andrmuel, @LuskeyNoah, @laroche, @sachinthegreen.

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, folks! There is a really cool addition this week which I thought deserved a quick video to walk you through what it’s all about. Support for CodeChecker was just added, which means that it’s now super easy to run a wide variety of static analysis and code style rules against your Zephyr applications, and get very detailed, actionable, reports. Just keep reading, it’s literally the next section below 🙂

Codechecker support

As mentioned in the intro, this the most exciting thing for me this week. I have to admit I wasn’t familiar with CodeChecker and it really is an impressive tool. Not only is it very powerful and versatile for… well… code checking 🙂 but it also comes with a complete server infrastructure and web UI that allows you to track how many defects get added/resolved over time, collaborate with coworkers on flagging what might be false positives, etc.

After having played with CodeChecker for a few minutes today, I realized it would be even better if I would share my findings with y’all, so I recorded a video which goes through some of the cool features of the tool, and that shows you how easy it is to enable CodeChecker support for any Zephyr project.’, so I recorded a video which goes through some of the cool features of the tool, and that shows you how easy it is to enable CodeChecker support for any Zephyr project.

Check out the documentation page for more information on how to get started.

LVGL getting some love

All the glue code for LVGL, that used to live in Zephyr’s fork of the upstream LVGL repo, has now been moved to the main Zephyr repository. (PR #61300)

This will make it much easier to improve LVGL support going forward, and there are actually several pull requests lined up already that are really promising with regards to bringing significant performance improvements to LVGL in Zephyr.

Boards & SoCs

• Support has been added for the YD-ESP32 dev kit. (PR #60067)
• Support for ARM Cortex-M4F core of the phyBOARD-Lyra from PHYTEC has been added. (PR #60603)

Samples

• The USB HID Mouse sample has been updated to leverage the Input subsystem. To quote the author, “this makes the sample much simpler and smaller”.
  Any board with USB device support and a set of 4 keys defined as INPUT_KEY_[0-3] will act as a mouse when plugged to a computer (for example, pressing Key-0 will be the equivalent of a left mouse button click). (PR #61104)

Drivers

• To facilitate synchronization between heterogeneous processors, a hardware spinlock driver API has just been introduced, with a driver implementation for Sequans SoCs. (PR #60625)
• ADC support is now available for ESP32-S3. (PR #60623)
• A new IPM (inter-process mailbox) driver is available for AMD-Xilinx platforms. (PR #61008)
• PWM support is now available for TI cc13xx_cc26xx. (PR #60828)
• New Synopsys DesignWare timer driver (PR #60783)
• New HyperRAM driver for Winbond W956A8MBYA. (PR #59845)
• Microchip XEC tachometer sensor now supports low-power mode. (PR #60718)
• Added support for Ambiq watchdog driver. (PR #61417)

A big thank you to the 9 individuals who had their first pull request accepted this week, 💙 🙌: @tnmysh, @0bijian0, @jcsxdev, @pbalsundar, @moradelk, @cesta2z, @Frauschi, @Christian-Marx, and @blemouzy.

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: