OSS + ELC EU 2026

This talk shares practical lessons learned from building multi-platform sensor firmware on Zephyr RTOS for industrial alignment tools. Zephyr enabled our team to deliver a high-quality solution despite an extremely tight project schedule. Early prototyping along with Zephyr’s native simulator (native_sim) enables firmware development and testing long before first PCBs are available. A modular architecture based on message queues and the Kconfig system allows for independent, testable components.
Finally, we dive into the hardware-facing challenges we encountered and solved: deterministic event handling under tight timing constraints and zero-CPU data acquisition using DMA-driven ADC pipelines.
Attendees will gain insights into structuring scalable Zephyr firmware, accelerating development without hardware, and building high-performance embedded systems with confidence.

Some SoCs have an embedded DAC peripheral, which allow to play low or medium resolution audio with minimal electronics, no advanced I2S external codec required.

In this talk, I present a list of ingredients required to make an acceptable audio output:
- The DAC: what it is, how it is different from PWM audio output or I2S peripherals
- DMA, your DAC’s best friend, to run continuously and without drops
- Debug something fast and real-time thanks to tracing

Then I will discuss implementation, with the codec subsystem. Example platform will be ST STM32F7 and Atmel ATSAM3X8E.

Finally, if nothing crashes or burn in the meantime, I will give a demonstration.

Pin multiplexing is always needed in embedded development. But when we start changing pins in a devicetree overlay, or when creating a custom board, things can quickly become confusing: build errors, wrong pin states, peripherals not starting, or hardware that simply does not behave as expected.

In Zephyr, the pinctrl subsystem is what connects the physical pins of the SoC with the peripherals we want to use. It defines the pin function, the electrical configuration, and the pin states used by the drivers.

In this talk, we will demystify pin multiplexing in Zephyr and explain how to use pinctrl in devicetree in simple words. We will go step by step through pin groups, pin states, common configurations, overlays, board files, and SoC-specific syntax.

We will also use practical examples for common peripherals and vendor families, and show how to debug the most frequent issues when customizing pins.

Embedded developers optimizing Zephyr applications often rely on software timers and GPIO toggles—intrusive techniques that alter the behavior they try to measure. Modern SoCs instead provide rich hardware performance counters across the system: CPU PMUs, interconnect/NoC monitors, and memory subsystem telemetry that capture cycles, cache behavior, bandwidth, and contention with near-zero overhead. Until now, Zephyr lacked a unified way to access these metrics.

This talk introduces Zephyr’s new portable **pmu.h** API, a cross-architecture abstraction for hardware performance monitoring. We present the first backend: an ARMv8-A PMUv3 driver that probes counters at runtime, self-calibrates CPU frequency, and maintains per-CPU state using IRQ-locked sequences for SMP safety.

Using real hardware benchmarks, we show how to measure context-switch cost, IRQ latency, cache behavior, branch prediction, and memory bandwidth. Attendees will learn how to add low-overhead profiling to their applications today and how the API will extend to RISC-V HPM, Cortex-M DWT, and SoC-level monitors without changing application code.

Pull request: https://github.com/zephyrproject-rtos/zephyr/pull/107016

Multi-core ARM Cortex-M SoCs are becoming increasingly common in today's market. Yet Zephyr RTOS only supports Asymmetric Multiprocessing (AMP) for these devices. The problem with AMP is that it limits true resource sharing, and leaves hardware parallelism underutilized. Symmetric Multiprocessing (SMP) addresses these issues by running a single Zephyr RTOS image with a unified scheduler across all cores. Zephyr RTOS currently lacks support for Symmetric Multiprocessing on ARM Cortex-M based SoCs and hence limits multi-core Cortex-M devices to AMP configurations. This talk presents a Proof-of-Concept implementation of SMP on Dual Core Cortex-M7 cores using the Infineon Traveo T2G (CYT4DN) SoC which runs a single Zephyr image with true parallel execution across cores.

The key framework challenges are: lack of a secondary boot up path for the secondary cores and the complications of unified timekeeping with per-core SysTick timers.

The talk details what has been achieved, the limitations that remain in timeout-driven context switching and scheduling, and outlines a path toward upstream-ready Cortex-M SMP support in Zephyr.

Linux-based Xen Driver Domains are powerful, but they increase the trusted computing base and add complexity to systems that need tight isolation, fast startup, and auditable software components.

This talk updates the Zephyr-based VIRTIO backend for Xen, an effort to run selected VIRTIO backend functions in small, purpose-built Zephyr driver domains. The goal is to preserve Xen’s proven architecture while enabling a finer-grained model: separate lightweight domains for network, storage, or platform-specific services.

Over the past half year, the project has moved toward platform integration. Upstreaming work has progressed, real-hardware demos are being developed on Renesas R-Car V4H, and integration with SoDeV, an SDV platform by Automotive Grade Linux, is underway.

The session will cover the architecture, current upstream status, and obstacles to using it across platforms. Attendees will leave with a realistic view of where Zephyr-based driver domains can reduce the trusted computing base, what challenges remain, and how to contribute to lightweight open-source driver domains for edge and automotive systems.

The NXP i.MX93 almost always gets the same software answer: Linux on the Cortex-A55, an RTOS on the Cortex-M33. But what if you don't need Linux?

Zephyr formally supports the i.MX93 A55 cores upstream (imx93_evk/mimx9352/a55 and /a55/smp), including GICv3 interrupts, PSCI power management, SMP, and the full peripheral set — Ethernet, CAN-FD, USB, MIPI-DSI, and more. Boot time drops, interrupt latency decreases, and memory footprint shrinks. And unlike other RTOS solutions, there are no per-unit royalties.

This session covers two things: first, a technical deep-dive into how Zephyr runs on an arm64 application core and looking at various peripherals and proving they work. Second, a live walkthrough of authoring a Zephyr BSP for the Ezurio Nitrogen93 SMARC — an i.MX93 SOM in the SMARC 2.2 form factor — covering DTS porting, pinctrl, driver enablement, and hardware validation.

Attendees leave with a clear framework for when Zephyr on Cortex-A beats Linux or a proprietary RTOS, and a practical template for porting any i.MX9x board to Zephyr.

DALI (Digital Addressable Lighting Interface) is the dominant standard for professional lighting control, yet firmware support for it has been absent from the Zephyr ecosystem — until now. This talk walks through the full journey of designing and upstreaming a DALI low-level driver into Zephyr mainline: from understanding the protocol's precise timing and bus requirements, to crafting an API that fits naturally within Zephyr's driver model, to surviving the community review process through multiple rounds of discussion and refactoring.

Along the way we also experimented with AI-assisted code review as part of our workflow, and we'll share what that was actually like in the context of a real upstream contribution.

We'll be honest about what was hard, what the community pushed back on, and what we'd do differently.