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).
- Another Rasperry Pi Pico based board, the WIZnet’s W5500-EVB-Pico, was also introduced by Ian (PR #66523). It is basically your typical Raspberry Pi Pico, except that it’s coupled with the W5500 Ethernet MAC/PHY.
- Added support for Intel Raptor Lake CRB board (PR #66696).
- Added support for ST STM32H750B Discovery Kit (Arm Cortex-M7, 128K Flash, 1M SRAM). (PR #66280)
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_wba55cgboard. - 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-regcompatible 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 newzephyr,native-linux-evdevbinding 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 legacyCONFIG_HEAP_MEM_POOL_SIZEKconfig may still be used but if it happens to be less than the computedK_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 KconfigCONFIG_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 statsshell 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!