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 ] : 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 ] : Bands to be scanned where 2: 2.4 GHz, 5: 5 GHz, 6: 6 GHz.
[-a, --dwell_time_active ] : Active scan dwell time (in ms) on a channel. Range 5 ms to 1000 ms.
[-p, --dwell_time_passive ] : Passive scan dwell time (in ms) on a channel. Range 10 ms to 1000 ms.
[-s, --ssids ] : SSID list to scan for.
[-m, --max_bss ] : Maximum BSSes to scan for. Range 1 - 65535.
[-c, --chans ] : 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-gpiodriver 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()andport_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!