OSS + ELC EU 2026

Clocks are easy to ignore until your first Zephyr BSP port — when UART, SPI, or DMA suddenly depend on device tree properties you have never touched.
This beginner-friendly talk explains how clocks work in Zephyr today: clocks as phandle-arrays (like pwms and gpios), the meaning of #clock-cells, and how DT macros connect DTS to driver code. We separate three everyday questions: enabling a clock, selecting its source, and reading its rate — mapped to clock_control_on(), clock_control_configure(), and get_rate().
We then cover practical porting decisions any SoC author faces: what to describe in device tree at boot, what to leave to runtime (for example power management), and common mistakes — wrong cells, gates versus muxes and over-modelling hardware in DT.
Finally, we look at where Zephyr is heading: RFCs for a Clock Management Subsystem propose richer clock trees and predefined clock states, closer to how silicon is wired. You will leave with a reusable mental model for today’s APIs and a map of tomorrow’s direction.
Audience: developers new to Zephyr, BSP porters, and device tree authors. No prior clock-driver experience required.

Microcontroller firmware is monolithic: one image, one failure domain, where a bug anywhere can crash everything. Yet modern MCUs ship with memory protection (MPU, MMU, or PMP), and Zephyr already has the isolation pieces - userspace, memory domains, kernel-object capabilities, watchdogs, zbus - never assembled into an application model.

This talk presents a service-oriented application layer for Zephyr: multiple memory-isolated apps running as managed units, each reaching hardware and the network only through a capability-gated service broker, so a misbehaving app cannot corrupt, starve, or crash its neighbors.

We build the missing keystone - an app-group lifecycle and a service broker - on top of existing Zephyr, and demonstrate it live: two isolated apps share one Wi-Fi stack, each making independent network requests; one hangs and another faults, both are killed and reclaimed, while the healthy app runs on. We close with hardware lessons and upstreamable RFC targets.

The Robot Operating System (ROS) is the de facto standard open-source middleware for building robot software, providing standardized messaging, tooling, and reusable components. ros2_control is a hardware-agnostic control framework focusing on the modular composition of control systems for robots, sharing of controllers as well as real-time performance.

Bringing ros2_control to embedded systems usually means bolting heavy DDS serialization and a bridge process onto microcontrollers. Zenbedded fixes this. It is a monolithic Zephyr, Zenoh, and ROS 2 framework built specifically for ros2_control. We put the transport, the RTOS client library, and the host-side hardware_interface plugin into one tight repository.
On the wire, we use a multi-tier transport that moves along a spectrum. You can choose between fully ROS-observable but slightly slower, or fully binary-encoded and fast, depending on what your control loop actually needs.
You'll leave with a pattern for running ros2_control on Zephyr-class hardware and a feel for working with ROS and ros2_control. We'll demo the stack balancing a real inverted pendulum on an ESP32, where latency is the difference between upright and toppled.

libiio is an open source C library developed by Analog Devices for interfacing with Industrial I/O (IIO) devices - ADCs, DACs, IMUs, RF transceivers, temperature sensors, and more. It underpins a broad ecosystem of host-side tools including Scopy, pyadi-iio, and MATLAB, all of which connect to targets over network, serial, or USB transports.

This talk walks through the architecture and practical mechanics of the port. We will cover how libiio's external backend integrates with Zephyr's device model, allowing any driver that implements the IIO device driver API to appear as a first-class IIO device. We will look at built-in bridge drivers that wrap any Zephyr ADC, DAC, or sensor device into an IIO device. We will also cover how the module integrates into the Zephyr build system using Kconfig, device tree, and snippets to enable libiio with minimal changes to an application.

We will demonstrate a Zephyr board being queried from Scopy and pyadi-iio, and close with a look at what is in progress - trigger support for deterministic sampling and streaming, and a USB transport as a complement to the existing UART and network transports.

Amalgamation is a build strategy used by projects like sqlite3 that combines C sources files into a single source file for various reasons. One such reason is to give the compiler greater visibility across the program for performance gains. sqlite3 claims 5-10% net performance gains in doing so.

Does applying the technique to parts of Zephyr net us any gains? If so why and where, and what are the trade offs involved?

The Linkable Loadable Extensions (LLEXT) subsystem supports loading and linking ELF files at runtime, enabling developers to add sandboxed plugin-like functionality to Zephyr applications. This session offers a discussion of how LLEXT works and how it can work for you, as well as an overview of the Extension Developer Kit (EDK). The EDK allows users to build extensions without building the main binary, enabling teams working on complex firmware to neatly divide efforts between individual loadable modules and the main binary.

Static program analysis can help us to save a lot of time to catch bugs before they cause real-world issues. Inspired by the already in west integrated puncover target I want to present and discuss my advances and experiments and how this especially can help during code review and development as part as the CI pipeline in application development to correctly configure necessary stack sizes and get warned on potential stack overflows.

Further ideas around how this could also benefit zephyr development are presented like checking subsystem enabled threads stack sizes across multiple boards.

When an embedded system crashes in the field, recovering the coredump often determines whether debugging takes hours or weeks. Zephyr has long supported coredumps over UART, but in modern industrial, IoT, and edge deployments the serial port is rarely accessible. Devices may be sealed in cabinets, deployed remotely, or connected only via network.

This talk introduces a new Zephyr coredump backend that streams crash data over UDP (IPv4/IPv6) at the moment of a fatal exception—no USB cable or physical access required. We will explore the design challenges of networking in the fatal path, including safely re-enabling interrupts so the NIC can transmit, and the ZCDU framing protocol used to packetize and reliably reassemble dumps from UDP datagrams. We also show how the host receiver integrates seamlessly with the existing Zephyr GDB workflow, making the switch from UART to Ethernet a simple Kconfig option. Attendees will learn how to enable fleet-scale crash capture and dramatically reduce time-to-root-cause for deployed Zephyr devices.

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

Most Zephyr CI talks focus on Twister with a single board. This talk covers what happens when your hardware spans continents, operating systems, and team boundaries, and every PR still needs to test against all of it.

Our Zephyr firmware targets proFPGA systems programmed via Windows-only scripts, Protium emulators on Linux servers with J-Links on Windows machines, MAX32xxx boards on Linux, and virtual platforms. Discrete teams — hardware, virtual platform, proFPGA, Protium, bare-metal, Debugger Scripts, and Zephyr — each own a different piece on different platforms.

We built CI that unifies all of this so a developer opening a PR gets feedback from real hardware regardless of board, country, or OS. The talk covers device-specific flashing automation, reusable workflows scaling from PRs to nightly runs, observability beyond pass/fail (memory footprint tracking, runner dashboards, test analytics), and the technical interfaces between teams that make it sustainable.

Every pattern is in production today, testing across 28+ boards in multiple countries and different toolchains on every pull request.