OSS + ELC EU 2026

Network connectivity is important part of Zephyr. This talk will give information of current status of the network stack.

Many spacecraft avionics and payload systems are already distributed embedded systems: onboard computers, payload controllers, sensors, and links must coordinate under strict reliability constraints. Aerospace has long used controlled onboard networks, from MIL-STD-1553 to Ethernet-based approaches such as TTEthernet. The next question is how open standards such as IEEE Time-Sensitive Networking (TSN) can work in open RTOS ecosystems such as Zephyr.

Based on my experience with TTEthernet, Zephyr, micro-ROS, and space OBC development, this talk asks what TSN on Zephyr should become. TSN is not one feature: traffic shaping, scheduled transmission, redundancy, policing, configuration, time synchronization, and hardware support all matter. Linux already has a mature TSN operations model around user-space tools such as tc and linuxptp. Zephyr has no Linux-style userland, so TSN needs Zephyr-native APIs, shell commands, samples, diagnostics, and management interfaces.

Attendees will learn why TSN matters for Zephyr, why Zephyr cannot simply copy Linux tooling, and what design questions remain for TSN-capable endpoints.

Zephyr has had its own abstraction for network buffers ever since the creation of its Bluetooth and Networking stacks that were part of the project's public launch back in 2016. The presenter is the original author of the buffer implementation and still acts as maintainer for it. The presentation will go through the original use cases, related design decisions, key terminology, and how the implementation has evolved over time as Zephyr has grown and received more users and requirements for the subsystem.

The presentation will also go through common mistakes/oversights that user make when starting to use the APIs, and show some best practices to avoid them. Finally, there will be an overview of some of the latest enhancements and new convenience APIs of the network buffer subsystem.

Over the past few years, the Zephyr documentation has continued to evolve, with steady improvements to content structure, discoverability, consistency, and the overall contributor experience. One thing that has proven especially valuable is having a regular community check-in where we can openly discuss what is working, what still gets in the way, and where our documentation priorities should be headed next.

Join this Birds of a Feather session to catch up on recent documentation improvements you may have missed, share feedback from your own experience using or contributing to the docs, and help shape what we should focus on in the year ahead.

Zephyr's new USB support has been in development for some time. It consists of USB device and USB host support. The new device support has been the default for the last two releases. Work on the device part also introduced initial support for the host stack at that time. This was primarily necessary to enable USB/IP support on the native_sim board.

Johann will start with a brief overview of the current status of USB support.

Johann will then present information on virtual device/host controllers and the virtual bus. These are not actually platform-dependent, but they are most often used with native_sim. Furthermore, he will explain how virtual device/host controllers make it possible to build USB applications for native_sim and then export them to a Linux client using USB/IP server support.

Johan will demonstrate that the main benefit of virtual device/host support and native_sim is the ability to test hardware-independent USB code in CI, even on a pull request basis. For example, we can test the behavior of the host/device stack in response to invalid or undefined requests.

Johann will either provide a few examples or point to the samples and specific tests in the repository.

The Zephyr USB host stack is still evolving and remains an experimental subsystem for many real-world applications. This session presents practical experience in enabling key USB host classes in Zephyr, including UVC (USB Video Class), CDC-ECM, and USB Hub support, along with a series of architectural improvements to the host stack.
The presentation highlights the challenges and lessons learned while bringing these features to Zephyr, including attach/detach handling, dynamic class matching for composite devices, device lifecycle management across class drivers, the core stack, and UHC drivers, dynamic configuration selection, and limitations in current APIs.
In addition, the session identifies gaps in the current USB host subsystem and outlines potential directions for future evolution. It aims to provide practical insights and guidance for developers working on USB host support in Zephyr.

Matter is an open-source application-layer connectivity standard for connected home devices built on top of Wi-Fi and Thread, technologies that are both supported in Zephyr. Until recently, Matter support on Zephyr was primarily delivered through vendor-specific downstream SDKs, but there has been a growing effort to collaborate upstream in both the Matter and Zephyr communities to improve integration between the two projects.

This session will explore the current state of Matter support in the Zephyr ecosystem, including how Matter is integrated today as an external middleware module. We will review ongoing development efforts across both projects to create a shared Zephyr platform abstraction layer for Matter, improve build system integration, maintenance and developer experience, and highlight opportunities for community contribution.

Attendees will gain an understanding of the architecture of Matter on Zephyr, recent upstream developments, the roadmap for future integration work, and how they can contribute to the effort.

Zephyr has mature driver APIs for IEEE 802.15.4, Bluetooth, Wi-Fi, and LoRa but none for radios running proprietary or custom link-layer protocols. The gap is most acute in Sub-1GHz but applies equally to proprietary 2.4GHz radios used in audio, gaming peripherals, and industrial control.
Current workarounds include using a protocol-specific API like ieee802154_radio_api or shipping standalone drivers and importing MAC assumptions that don't belong at the PHY. The result is duplicate code across out-of-tree drivers that lock applications to a single chip and block upstream contribution. The problem spans standalone transceivers and integrated SoCs across TI, Silicon Labs, Microchip, and ST.
This talk revives Zephyr RFC #43201 (closed 2022) with a focused proposal: a new prop_rf driver API covering only physical-layer operations, leaving link-layer concerns to the application or protocol implementer. Three principles drive the design: applications port across vendors without API lock-in; vendor HALs remain free to expose custom features via device-specific extensions; and the API works for both external transceivers and integrated SoCs.