Zephyr RTOS Update | November 4, 2025

[ 1 ] Top Story

Zephyr is about to “take the stage” at two major global summits!

The Zephyr project is entering a spotlight moment. Tomorrow (November 5), the eyes of global developers will be focused on two major events:

North America (In-person): Zephyr will hold an in-person developer meetup in Anaheim, coinciding with the Embedded World North America 2025 exhibition, where Infineon, NXP, and Renesas will be present to offer “benefits” (sponsored development board giveaways).

Global (Online): The well-known tech media Elektor will simultaneously host an online conference titled “Zephyr – Open RTOS for Tomorrow’s Devices,” delving into Zephyr’s security practices, TinyML applications, and Rust development.

Core Storm:

With both online and offline events happening simultaneously, this marks the beginning of a “rapid expansion phase” for the Zephyr community and its commercial ecosystem.

[ 2 ] Community Pulse

• Hot Blog: Smooth Debugging of Zephyr with VS Code

  Golioth (or Nordic DevZone) published a high-traffic blog yesterday detailing how to configure VS Code’s launch.json for one-click compilation, downloading, and breakpoint debugging of Zephyr projects (especially multi-repo projects managed by west).

  [Brief Interpretation]: Half of Zephyr’s “high learning curve” is stuck on “incompatible debugger configuration.” The emergence of this “nanny-level” tutorial is paving the way for Zephyr to break into new circles and attract new developers.

• 4.3.0 RC3 (Hard Freeze) is Coming Soon

  Reminder: The release window for version 4.3.0 will enter the RC3 (hard freeze) phase on **this Friday (November 7)**. This means the community is in the “final stages,” focusing on clearing the backlog of PRs.

[ 3 ] Hardcore Updates

• 4.3.0 Adds Massive Board Support

  (Note: This is a supplement to the 6:53 AM update)

  One of the biggest highlights of version 4.3.0 is the “crazy” hardware support. The draft of release-notes-4.3.html shows that new support includes:

  • Adafruit: Feather RP2040 Adalogger, Feather RP2040 CAN bus, Metro RP2350

  • AMD: Versal Net APU Development Board

  • Ai-Thinker: ESP32-CAM

  • Analog Devices: max32658evkit

  [Brief Interpretation]: Zephyr is catering to both the “professional” (AMD Versal) and “maker” (ESP32-CAM) markets.

[ 4 ] GitHub 24h

Data Dashboard (Past 24h):

• zephyrproject-rtos/zephyr (main branch)

  • Total Commits: 38

  • New PRs: 12

  • Merged PRs: 17

• Active Subsystems:

  • drivers/: 11 commits (mainly i2c, pinctrl, sensor)

  • doc/: 9 commits

  • tests/: 6 commits

  • samples/: 5 commits (LVGL Demo memory pool adjustments)

• Active HAL Repositories:

  • hal_stm32: (Updated 11 hours ago)

  • arduino-core-zephyr: (Updated 13 hours ago)

[Brief Interpretation]:

The data is consistent with the 6:53 AM update; the main branch is still in the “fixing and finalizing” stage. “Merged PRs (17)” > “New PRs (12)” indicates that the community is sprinting towards the RC3 hard freeze on November 7. hal_stm32 and arduino-core-zephyr remain the most active points of investment from vendors and the community.

[ 5 ] Weekly Deep Dive

Topic: Kconfig vs DTS, Zephyr’s “Configuration Duo”

(Note: This content is different from the DTS section in the 6:53 AM update)

If DTS (Device Tree) describes **”what the hardware looks like,” then Kconfig describes “what the software needs”**.

[Brief Interpretation]:

Kconfig (originating from the Linux kernel) is a powerful “configuration menu” system. It addresses three nightmares caused by traditional #define:

1. Dependency Hell:

   • Previously: You #define USE_FATFS, but forgot #define USE_SD_CARD, resulting in a compilation error.

   • Now: config FATFS in the Kconfig file depends on SD_CARD. If you select FATFS in the menu, it will automatically select SD_CARD for you or prompt you if the dependency is not met.

2. Configuration Conflicts:

   • Previously: You defined both #define USE_LOW_POWER_UART and #define USE_HIGH_SPEED_UART, and the compiler silently chose the last one, causing the system to crash.

   • Now: choice syntax. Kconfig forces you (in the menu) to choose one of “low power” or “high speed”.

3. Memory Black Holes:

   • Previously: You had no idea how much RAM/Flash a certain macro occupied.

   • Now: Kconfig allows you to define config MAIN_STACK_SIZE and modify it directly in the menu.

Conclusion:

DTS (Device Tree) manages “hardware boards,” while Kconfig manages “software functions.” Zephyr uses this combination to achieve a unified “code portability” and “function customizability”.

[ 6 ] My Hot Take

[ 👆 Replace with meme/image.png ]

This Issue’s Hot Take: Is Zephyr’s “all-encompassing” model a good thing or a bad thing?

I actually think this is precisely what makes Zephyr the most “formidable”. It is no longer just an “RTOS”; it is becoming the “Linux” of the RTOS world.

When an operating system no longer cares about supporting “a few boards” but starts to **”define”** the “default layers” for all new hardware (RP2350, Versal), it has already won. It is transitioning from “one of the options” to “the industry standard”.

What do you think? Is Zephyr’s “all-encompassing” approach a plus or a minus?