The First Issue of Zephyr Insider: In-Depth Weekly

This week (11.03 – 11.07) marks a significant moment in the history of Zephyr. We witnessed the final sprint towards the “hard freeze” of version 4.3.0, a textbook rescue of a “high-risk bug,” and a global “buzz” in the Zephyr ecosystem.

This week represents a turning point for Zephyr from being “usable” to “reliable.”

🌐 Community Pulse (Weekly Summary)

“Hard Freeze” Completed: Zephyr 4.3.0 completed RC3 (hard freeze) on November 7. The main branch has been sealed, the kernel is stable, and the community merged 45 PRs in the 24 hours before the “lockdown.”
“Global Buzz Day”: On November 5, Zephyr held two major summits simultaneously in North America (offline) and Elektor (online).
Official Blog: The Zephyr official website published a blog post on November 4, previewing the North America Meetup on November 5. The article prominently featured NXP, Renesas, Qt Group, and Antmicro as keynote speakers.
IAR Official Announcement: IAR (a well-established toolchain) officially announced support for Zephyr with “production-level support,” which is a strong boost for Zephyr’s entry into the “safety certification” field.

🔥 Community Hot Topics (5 Highlights)

Here are the “5 hot posts” you wanted. This week’s community discussions (Discord/mailing list) were 100% focused on “4.3.0 freeze” and the “11.05 summit”:

“CAN Bus Crisis (PR #98712)”

Heat Level: ⭐️⭐️⭐️⭐️⭐️
Topic: The reentrancy bug in can_tx_callback was almost the “main character” of this week’s CI system. The community observed the entire process from “discovery” to “questioning” and finally to “last-minute merging” in this “high-risk bug rescue.”
[Quick Report Interpretation]: This is a “perfect advertisement” for the Zephyr TQC process.

“Rust vs C (in Driver)”

Heat Level: ⭐️⭐️⭐️⭐️
Topic: The “Rust topic” at the online summit on November 5 ignited discussions in the Discord #rust channel. The focus shifted from “Can Rust write apps?” to “Can Rust write drivers?”
[Quick Report Interpretation]: The consensus is that “perfect for application layer, dangerous for driver layer.” The macros and linker magic of C language remain a “moat” that Rust struggles to cross.

“4.3.0 API Deprecation Wails”

Heat Level: ⭐️⭐️⭐️
Topic: Discussions about the deprecation of the third parameter in the SPI_DT_SPEC_GET macro appeared on the mailing list.
[Quick Report Interpretation]: Experiencing “growing pains” is a good sign, indicating that the API is moving towards “unification” and “standardization,” at the cost of older users needing to git blame to complain.

“VS Code Debugging is Hot Again”

Heat Level: ⭐️⭐️
Topic: With the upcoming release of 4.3.0, the “how to configure VS Code to debug Zephyr” tutorial on Golioth and Nordic DevZone has been “dug up” and shared again.
[Quick Report Interpretation]: The ease of use of the toolchain is the first hurdle for Zephyr’s “new user acquisition.”

“What Does ESP32-CAM Actually Support?”

Heat Level: ⭐️⭐️
Topic: Version 4.3.0 added support for the Espressif ESP32-CAM. However, the community immediately questioned: “Does this mean that Zephyr’s Camera driver subsystem is now mature?”
[Quick Report Interpretation]: The answer is no. The current support is only for “lighting up” (Blinky) and basic GPIO, far from being able to “run a camera.”

🎓 Deep Dive

Topic: The “Soul” of Zephyr – Device Driver Model (DDM)

Previously, we discussed DTS (hardware appearance), Kconfig (software functionality), and West (project management). However, the “soul” of Zephyr is its Device Driver Model (DDM).

[Quick Report Interpretation]: DDM solves an ultimate problem in embedded C programming: “How to know the device at runtime during compile time?”

Previously (FreeRTOS/Bare-metal): You needed a I2C_Handle_t h_i2c1 global variable. You manually called My_I2C_Init(&h_i2c1) in main(). Then, your sensor task Task_Sensor had to extern this h_i2c1 to use it.
Now (Zephyr DDM):

Driver: You write a i2c_my_driver.c, calling the DEVICE_DT_INST_DEFINE() macro inside it.
DTS (Hardware): You declare my_i2c_node in dts.
Kconfig (Software): You config I2C_MY_DRIVER=y.
Linker: At compile time, the “linker” sees (1) (2) (3), automatically binds your driver and DTS node together, and places it in a read-only memory area, assigning a Device ID.
Application: You no longer need to extern any handles. You only need const struct device *dev = DEVICE_DT_GET(DT_NODELABEL(my_i2c_node)).
Kernel: Before main, the Zephyr kernel will automatically traverse that “read-only memory” and call the _init functions of all drivers to complete initialization.

Conclusion: DDM is a framework based on “linker magic” and “macro magic” for **”automatic initialization and elimination of global variables”**. It transforms all Zephyr drivers (device) into “plug-and-play” objects, which is the cornerstone for managing over 1000 boards.

✨ Project Spotlight

Project: ZSWatch (Zephyr Smartwatch)

If you think Zephyr can only run in “black boxes,” ZSWatch will change your perception.

ZSWatch is a fully open-source smartwatch firmware, 100% based on Zephyr. It runs on nRF52832/nRF52840 and supports:

LVGL graphics library (gorgeous UI)
Touchscreen / Physical buttons
Pedometer (LIS2DH)
Heart rate and blood oxygen (MAX30101)
Bluetooth notifications (integrated with mobile GADGETBRIDGE)

[Quick Report Interpretation]: ZSWatch is the ultimate demonstration of Zephyr’s **”ecosystem integration capability.”** It combines Zephyr’s Bluetooth stack, sensor drivers, LVGL porting layer, and power management (PM) all together. This is the best example of Zephyr’s entry into the “consumer electronics” field.

🔥 My Hot Take

This Week’s Hot Comment: “The perfect conclusion to the CAN bus crisis.”

This week’s CAN bug (PR #98712), from “discovery” to “merging,” I (the operator) observed the entire process, feeling both cold sweat and relief.

Cold Sweat: This is CAN! A high-reliability driver! How could a “reentrancy bug” be discovered only in the RC stage?
Relief: It was discovered, publicly discussed, repeatedly “whipped” by CI, and finally merged before the “hard freeze.”

[Quick Report Interpretation]: This precisely demonstrates the fundamental difference between Zephyr and traditional “legacy RTOS.”

Legacy RTOS: Bugs are hidden, relying on customers (you) to be “paid testers,” and finally just releasing a patch.
Zephyr: Bugs are exposed to the sunlight, diagnosed by global developers, and “tortured” by CI.

This bug’s emergence is not a “stain” on Zephyr, but rather a “medal” for Zephyr’s process (TQC).

What do you think? Would you dare to use a “4.3.0” that just fixed a high-risk bug?

📰 Source Links

Zephyr 4.3.0 Official Log (Draft)
Zephyr Official Release Schedule (Wiki)
November 5 Offline Meetup (Zephyr Official Blog)
ZSWatch (GitHub Repository)
Zephyr Device Driver Model (DDM) Official Documentation

💬 The Truth Lies in the Comments

This Week’s Topic (Choose One):

4.3.0 has “locked down,” which PR/feature were you most looking forward to that “missed the boat”?
What is the most bizarre pitfall you (or your colleagues) have encountered with the CAN bus?