The Zephyr community came together at Open Source Summit India 2026 in Mumbai to share knowledge and explore developments, tooling, and real-world applications across embedded systems.
In this first post-event blog, we highlight two sessions from the Zephyr track. One explored why Zephyr can initially feel overwhelming to bare-metal developers, while the other examined how downstream Zephyr releases can keep pace with upstream development.
Does Zephyr Scare the Bare Metal Embedded Developer World? – Khasim Syed Mohammed & Soumya Tripathy, Texas Instruments
In this session the speakers examined the challenges bare-metal developers may face when adopting Zephyr.
The session began by defining bare-metal programming as directly accessing a microcontroller’s registers and writing the code needed to control the hardware. While this approach may work for simple applications, complexity increases as developers add multiple peripherals, threading, interrupts, DMA, testing, power management, security, and networking. The speakers explained that developers can eventually find themselves recreating capabilities that Zephyr provides as part of a standard open source RTOS framework.
Using side-by-side examples involving GPIOs, ADCs, and interrupts, the session mapped familiar bare-metal concepts to their Zephyr equivalents. It explained how Zephyr introduces standardized drivers and abstractions through features such as Kconfig and devicetree, while still allowing developers to access hardware registers directly. The speakers also discussed Zephyr’s threaded interrupt model and the option to use zero-latency interrupts for time-critical applications.
Developers do not need to adopt every Zephyr capability at once. They can begin with the build environment and basic drivers before gradually exploring devicetree, shell functionality, threads, queues, security, power management, and networking.
The session also compared bare-metal and Zephyr development in the AI era, highlighting how Zephyr’s standardized APIs, open source codebase, upstream support, community, portability, and ecosystem provide a structured framework for embedded application development.
Downstream Zephyr RTOS Release Management – Keeping up With Upstream Pace – Parthiban N, Linumiz
In this session Parthiban discussed how downstream Zephyr releases can be maintained while keeping pace with upstream development.
Zephyr is ten years old, with more than 3,000 contributors and over 15,000 commits per release. Drawing on Linumiz’s work with silicon manufacturers including Infineon and Texas Instruments, Parthiban explained how the company maintains open source downstream Zephyr releases for customers and product development.
The session reviewed Zephyr’s regular and Long-Term Support release cycles, as well as the role of the Zephyr SDK and west in managing toolchains, modules, board support packages, applications, and other dependencies. Parthiban also demonstrated the challenges of migrating applications between Zephyr releases. These can include changes to Python dependencies, directory structures, devicetree files and bindings, driver APIs, and other interfaces, followed by possible runtime issues when the software is tested on hardware.
Parthiban presented different approaches to downstream maintenance: tracking upstream development closely, moving from one LTS release to another, or remaining on a selected release and backporting the required features, bug fixes, and security fixes. He explained that release managers must monitor upstream development, identify which changes are relevant to their products, and maintain downstream patches on top of the selected Zephyr release.
The session also covered reproducible builds, security updates, functional safety considerations, code review, and testing on real hardware. Parthiban described how Zephyr’s Twister tool can be used with remote hardware-testing infrastructure to compile, flash, and test software on boards located elsewhere.
He also discussed the growing use of AI-generated code and emphasized the continuing need for human review, testing, and evaluation. The session concluded that maintaining downstream Zephyr releases requires a structured release process, regular upstream monitoring, careful backporting, and testing on real hardware.
Together, these sessions explored two areas of Zephyr development. The first showed how familiar bare-metal concepts can be mapped to Zephyr and how developers can adopt its features gradually. The second examined how downstream releases can keep pace with upstream development through release planning, monitoring, backporting, code review, and testing on real hardware.
Thank you to Khasim Syed Mohammed, Soumya Tripathy, and Parthiban N for sharing their experiences, and to everyone who joined the Zephyr track at Open Source Summit India 2026.