2026 Zephyr 开发者大会 10 月 7 至 9 日在捷克布拉格举办，ZDS 已经连续 4 年作为嵌入式开源峰会（EOSS）的一部分举办。

本次开发者大会一共有 42 个演讲/会议，截至发文时 4 个没有文档。另外今年举行了一场社区颁奖，同时连续 3 天都有专门的场地全天开放用作 Zephyr Community Hub，为社区成员提供了一个交流平台，用于交流心得、分享研究成果、提出问题，和志同道合的人聊天。

内容总结

本届 ZDS 最集中的大方向是

• 功能安全认证（IEC 61508 / ISO 26262 / IEC 60730，多个演讲从不同角度推进）
• 虚拟化与混合 OS（Xen + Zephyr Dom0/DomD、Linux + Zephyr 异构协作）
• 可测试性与可观测性（假驱动、硬件 CI、FPGA 路由、PMU、运行时观测工具、静态栈分析）
• AI 不只是代码生成工具，也是工程治理议题

从整个演讲内容来看，2026 ZDS 的关注点不局限于「Zephyr 支持哪些芯片、有哪些驱动」，而是转向如何构建一个可验证、可移植、可协作、可长期维护的嵌入式平台。

AI 与 Zephyr

AI 是本次 ZDS 中一个值得单独看待的主题。AI 削弱的是项目代码规模的优势，这对所有的软件项目都一样，但不会削弱 Zephyr 生态的价值，统一的标准平台与接口和自动化验证。从 ZDS 议程只能看出社区正在讨论和尝试 AI 工具，并不代表 Zephyr 已经有成熟的 AI 开发模式和架构。

值得关注的趋势

演讲文档分类 & 概览

今年不再提供演讲文档的网盘链接，文档可以通过会议链接在页面中下载，再过段时间官网应该会发布演讲视频。

01 项目战略、生态治理与社区协作 x3

项目长期发展、社区治理与协作方式，以及 AI 对 Zephyr 生态定位和文档工作的影响。

Zephyr at 10: Scaling an Open Source RTOS for the Next Decade - Anas Nashif, Intel^[1]

无文档

Zephyr 项目 TSC 主席 Anas Nashif 关于 Zephyr 十周年发展的战略演讲。从项目可持续性的角度探讨 Zephyr 的发展历程。演讲重点阐述当前模式的优势所在、扩展压力显现之处，以及社区需要解决哪些问题才能确保 Zephyr 在未来十年保持健康发展。演讲内容涵盖维护人员的精力、代码审查延迟、基础设施负载、测试和样本增长、供应商支持、下游兼容性、长期支持、安全更新、依赖管理，以及如何在统一的上游需求与产品和平台特定创新需求之间取得平衡。

Sponsored Panel: If AI Can Write Drivers, Why Do We Need Zephyr and Should We Make Zephyr AI Ready? Moderated by Andrei Aldea & Khasim Syed Mohammed, Texas Instruments Inc^[2]

研讨会，无有效文档

讨论生成式 AI 对嵌入式开发领域的冲击，重新定义 Zephyr 在 AI 时代的存在价值。承认 AI 已能高效生成驱动、BSP、设备树等底层代码，「编写代码」本身趋于廉价化；这并不意味着 Zephyr 可被取代：当代码生成门槛降低，标准化、可移植性、可维护性、测试体系、社区协作与长期生态支持反而更能放大 AI 的价值。

Zephyr Documentation BoF - Benjamin Cabé, Linux Foundation^[3]

最近一年 Zephyr 文档变化的回顾，以及文档工作中 AI 的应用情况。

02 功能安全、合规与安全响应 x6

功能安全机制、认证证据、软件架构独立性、SBOM/法规合规与漏洞响应。

Practical End-to-End Traceability for Zephyr’s Path To Safety Certification - Tobias Kästner & Andreas Kurz, inovex GmbH^[4]

Zephyr 虽已开始 IEC 61508 认证的需求收集工作，但需求-测试-代码三者间的追溯链路缺失是阻碍安全文档生成的关键瓶颈。演讲者提出不引入新工具、不增加开发者负担的解决思路——复用 Zephyr 社区已有的 Doxygen/Sphinx 文档基础设施，通过源码与测试的结构化注释自动提取信息，构建从需求到实现再到验证的端到端可追溯链，并生成认证所需的审计文档（需求规范、测试报告、可追溯性矩阵等）。

• 可追溯性模型：需求用 StrictDoc 管理（reqmgmt 仓库），测试用 @verifies Doxygen 注解关联需求，设计文档用 Sphinx .. design:: 指令回链需求。
• zdocs 工具：以声明式 documents.yaml 构建可审计文档集，可从 Twister 测试结果生成测试报告。
• affirmatrix 工具：用边哈希检测追溯，git 历史即审计记录。

CRA Readiness With SPDX 3 SBOMs in Zephyr - Benjamin Cabé, The Linux Foundation^[5]

Zephyr 固件的复杂性远超普通软件——其构建涉及上游代码、厂商 HAL、二进制 blob、Kconfig/devicetree 配置及生成文件等多层组件，且并不是所有构建时依赖都进入最终镜像。Zephyr 集成的 SPDX 3.0 SBOM 方案，记录「哪些组件存在」，同时通过构建系统深入展示「为何被引入」及「组件间如何关联」，实现构建感知的精准软件物料追踪。该技术支撑两大目标：一是高效漏洞管理，消除未使用组件导致的误报；二是 CRA 法规就绪，以机器可读的标准格式提供产品透明度、漏洞响应能力与安全更新追溯所需的完整技术文档，为嵌入式设备厂商提供可落地的合规基础架构。

AI in Zephyr PSIRT: Lessons From the Front Line - Flavio Vinicius Alvares Ceolin, Hubble Network & David Brown, Linaro^[6]

Zephyr RTOS 安全响应团队（PSIRT）应用 AI 的专题演讲。Zephyr 的安全响应由小型志愿者团队承担，面对百万行代码库中持续增长的漏洞报告，传统的人工流程——漏洞分类、源码确认、CWE 映射、CVE 记录撰写及多分支跟踪——使维护者压力极大。

演讲分享了将 AI 引入该高风险领域的实践经验：

• 通过源代码树 grounding 实现精确到文件行号引用的分析
• 依据严格模式自动生成 CVE 记录以防止 AI 幻觉

发布漏洞的时间从数小时压缩至数分钟。同时也讨论了失败案例，强调建立「人工在环」（human in the loop）防护机制的必要性。演讲提供了一套可复用的实施蓝图与检查清单，为其他开源项目整合 AI 辅助安全流程提供重要参考。

Demystifying Functional Safety in Zephyr RTOS - Alexandre Bailon, BayLibre^[7]

演讲解释什么是功能安全，以及为什么功能安全对于 Zephyr 至关重要。演讲谈到安全工作组，以及该工作组如何在满足认证要求的同时，尽可能减轻贡献者和维护者的负担。讨论目前在推进 Zephyr 功能安全支持方面，社区参与的举措和机会。

• Zephyr 只是「组件」而非最终产品；认证 Zephyr ≠ 认证产品，系统集成（危害分析、编译器鉴定）由集成方完成。
• 长期独立分支维护安全修改的策略在 Zephyr 高速开发节奏下失败；新策略是安全改动直接进 main，之后切出 auditable 分支产出认证快照。
• 需求管理用 StrictDoc 放在独立 reqmgmt 仓库，写需求的过程甚至发现了真实 bug（内存屏障在部分平台编译为空）。
• 目标 2027 年完成 IEC 61508 和 ISO 26262 首次认证；大多数贡献者不受影响。

Bringing IEC 60730 Class B Functional Safety To Zephyr - Andrej Butok, NXP Semiconductors^[8]

IEC 60730 B 类标准规定了家用电器自动电气控制的安全要求，强制要求诊断机制，以确保在故障情况下安全运行。尽管 IEC 60730 标准已被广泛采用，但各大 MCU 厂商各自提供封闭、重复造轮子的预认证 Class B 库，无法协作。NXP 解决方案：

• 提出统一 iec60730b_test_*() API + Kconfig 使能，后端可切换：NXP 认证裸机库 / 基于 Zephyr 标准驱动的可移植未认证版本。
• 以外部 West 模块交付（mcux-safety-iec60730b），附上电自检 + 运行时周期性安全测试线程的参考示例。
• 目标上游化到 subsys/safety/iec60730b_test，并推动 NXP 库改为宽松许可证，成为跨厂商社区项目。

Reverse Engineering Zephyr's Software Architecture for Safety-Critical Use - Roberto Bagnara, BUGSENG / University of Parma^[9]

无文档

演讲介绍一项正在进行的研究工作：利用静态分析技术，逆向分析 Zephyr 实际的软件架构约束。该方法从具体的 Zephyr 配置出发，对软件组件进行建模，分析组件之间的函数调用和数据访问，识别组件间的依赖关系，并将分析结果与项目预期的分层架构进行比较。

演讲展示这种分析方法如何通过明确化、可验证的软件层面独立性，为安全论证提供支持。同时介绍如何利用同一模型开展变更影响分析（Change Impact Analysis）：当已通过资格认证的 Zephyr 版本或配置发生演进时，该模型能够帮助确定哪些组件、假设、测试以及安全性证据会受到影响。

03 系统架构、操作系统协同与隔离 x8

Zephyr 的系统定位、与 Linux/Xen 的协作、应用隔离、扩展机制、多核与应用处理器架构。

Ten Years of Zephyr: Replace Linux, or Work With It? - Iuliana Prodan, NXP Semiconductors^[10]

演讲展示如何在同一芯片上并行运行 Linux 和 Zephyr，所用组件均来自 Zephyr 目前提供的版本：IPC 服务层、用于两核间消息传递的 OpenAMP 和 RPMsg、邮箱和共享内存后端，以及用于 Linux 启动和停止 Zephyr 固件的机制。基于 NXP i.MX 和 i.MX RT 平台说明这些组件如何协同工作，以及难点所在——内存布局、缓冲区大小、地址转换和关机顺序。

观点：「Zephyr 取代 Linux」是误解：RTOS 适合固定功能/即时启动/易认证产品，Linux 保留在富 UI/大生态场景。

Where Zephyr Fits in Space Computer Architecture - Yasushi Shoji, Space Cubics Inc.^[11]

从系统架构的角度探讨 Zephyr。基于 Space Cubics 的 OBC 开发经验以及近期关于太空级 Linux 的讨论，探讨 Zephyr 在未来空间系统中的应用方向：任务实时操作系统（RTOS）、有效载荷控制器操作系统、监控/控制平面操作系统，或是 Linux 的配套操作系统。目前太空领域已有一些可靠的 RTOS 选择，但如果整个生态系统能够围绕启动、恢复、可观测性、硬件控制和职责边界构建清晰的架构，Zephyr 就能发挥其价值。

Zephyr 的三种角色：主飞行 RTOS、异构 SoC 中「伴飞」Linux 的监督与恢复 MCU。

Zephyr and Xen in Automotive Mixed-OS Systems: Building Safety Readiness and Upstream - Harunobu Kurokawa, Renesas Electronics Corporation^[12]

在汽车系统领域，Zephyr 可以作为一个功能有限且定义明确的小型 RTOS 域来使用。演讲将 Zephyr 和 Xen 视为互补组件。Xen 提供域隔离和资源分区，Linux 托管高级服务和集成层，而 Zephyr 处理特定的实时操作系统（RTOS）功能。会议概述了基于开源软件的汽车软件中的角色划分。

以 Linux/AGL 混合操作系统集成的案例研究，探讨将 Zephyr 和 Xen 应用于汽车系统时需要解决哪些问题，以及如何与社区共同推进这些工作。

Apps, Not Firmware: A Service-Oriented Application Layer for Zephyr - Sylvio Alves, Espressif Systems^[13]

无文档

介绍一种面向 Zephyr 的面向服务的应用层架构：多个应用以受管理的独立单元运行，并通过内存隔离彼此保护。每个应用只能通过受能力权限控制的服务代理（service broker）访问硬件和网络，从而确保某个行为异常的应用不会破坏其他应用的内存、耗尽其他应用的资源，或导致其他应用崩溃。

在现有 Zephyr 的基础上，构建应用组生命周期管理机制（app-group lifecycle）和服务代理（service broker），并现场演示：

• 两个相互隔离的应用共享同一个 Wi-Fi 协议栈，同时各自独立发起网络请求。
• 其中一个应用发生挂起，另一个应用触发故障。
• 系统分别终止这两个异常应用并回收其占用的资源，而运行正常的应用继续工作，不受影响。

Multiple Cores, One Zephyr: The Path To Cortex-M SMP in Zephyr - Sanjay Vallimanalan, Linumiz^[14]

Zephyr RTOS 尚不支持基于 ARM Cortex-M 的 SoC 使用 SMP，因此这类多核设备只能采用 AMP 配置。本次分享介绍一个概念验证（Proof of Concept，PoC）实现：在英飞凌（Infineon）Traveo T2G 系列的 CYT4DN SoC 上，为双核 Cortex-M7 实现 SMP 支持。该方案运行单一 Zephyr 固件映像，并让两个核心并行执行任务。

方案面临的主要框架挑战包括：

• 缺少辅助核心启动路径：Zephyr 需要建立一种机制，使主核心能够正确启动并初始化辅助核心。
• 统一时间管理的复杂性：每个核心都有独立的 SysTick 定时器，如何在这种硬件条件下实现统一、可靠的系统时间管理，是一项重要挑战。

详细介绍目前已经实现的功能、在基于超时机制的上下文切换与任务调度方面存在的限制，以及未来如何逐步完善实现，推动面向 Cortex-M 的 SMP 支持达到可合并至 Zephyr 上游代码库的水平。

通过该演讲可了解在 Cortex-M 多核平台上实现 SMP 的关键技术难点，以及从概念验证走向正式上游支持所需解决的问题。

Zephyr-Based VIRTIO Backend on Xen: From Tiny Driver Domains To Real Hardware Integration - Hiroshi Tokita, Independent^[15]

用 Zephyr 作为 Xen 的 VIRTIO 后端（DomD），从微型驱动域走向真实硬件集成。

常规 Linux 充当 DomD 过于臃肿；用多个 Zephyr DomD 替代，实现路径：XenStore 配置 → ioreq server 虚拟 MMIO → 事件通道中断 → VirtIO 寄存器解析 → virtqueue 处理。

QEMU 演示成功：Zephyr DomD 约 87 KB vs Linux DomD 约 832 MB，小约 4 个数量级。真实硬件（R-Car V4H）难点：4 KB 页内多外设寄存器共享、pinctrl/clock 共享基础设施、TrustZone 专有初始化。

Linkable Loadable Extensions and the Extension Developer Kit - Lauren Murphy, Independent^[16]

可链接可加载扩展（Linkable Loadable Extensions，LLEXT）子系统支持在运行时加载和链接 ELF 文件，使开发者能够为 Zephyr 应用程序添加类似插件的功能，并在沙箱隔离环境中运行这些扩展。

演讲介绍 LLEXT 的工作原理、它能够为开发者带来的优势，以及如何在实际项目中使用它。同时介绍扩展开发工具包（Extension Developer Kit，EDK）。EDK 允许在无需重新构建主程序二进制文件的情况下，独立构建扩展模块。这使得开发复杂固件的团队能够将开发工作划分为两部分：一部分负责主程序，另一部分负责各个可独立加载的模块。

Zephyr on the Big Core: Real-Time on the I.MX93 Cortex-A55 With Zephyr - Ryan Erickson, Ezurio^[17]

在 i.MX93 的 Cortex-A55 大核上直接运行 Zephyr 实现实时计算。

• 打破「Linux 占 A55、M33 做实时」的常规划分：U-Boot 直接将 Zephyr 启动到 A55 上。
• SMARC 载板抽象为独立 shield 便于复用；SMP 验证：16 线程 Pi 计算单核 4 ms、双核 2 ms，应用零改动。
• 大量修复回馈上游（NXP HAL ARM64、Wi-Fi NX611、LE Audio、USB device 时钟）；以太网/Wi-Fi/蓝牙/USB 已可用。
• 明确指出 Zephyr 目前完全没有 HDMI 支持，是社区贡献机会。

04 架构移植、SoC、BSP 与硬件底层 x3

CPU 架构支持、时钟、引脚复用及 BSP/底层硬件适配。

From Reset To Main(): Porting Infineon TriCore AURIX To Zephyr - Parthiban N, Linumiz & Christoph Seitz, Infineon Technologies AG^[18]

演讲介绍在 Zephyr 中添加 TriCore 架构支持并使英飞凌 AURIX TC3x 和 TC4x 器件得以实现的上游工作（https://github.com/zephyrproject-rtos/zephyr/pull/107516）。从 CPU 复位开始，逐步介绍启动第一个 Zephyr 线程所需的关键架构步骤，包括陷阱和中断处理、基于上下文保存区（CSA）的上下文切换以及系统定时器集成。还介绍架构层之外所需的工作，包括 SoC 支持、板级启用以及基于 QEMU 的开发和测试。最后，讨论将新架构引入 Zephyr 面临的挑战，从工具链和 CI 集成到 HAL 依赖项和生态系统支持，以及汽车和安全关键系统所需的剩余工作。

Clocks in Zephyr: A Practical Guide for BSP Developers (Lesson Learned From a Real Porting) - Martin Hoff, Silicon Laboratories^[19]

面向初学者的分享，讲解 Zephyr 当前的时钟工作机制：时钟如何以 phandle 数组的形式表示（类似于 pwms 和 gpios），#clock-cells 的含义是什么，以及设备树（DT）宏如何将 DTS 配置与驱动代码连接起来。

区分日常开发中三个常见的问题：使能时钟、选择时钟源，以及读取时钟频率，并分别介绍与之对应的 API：clock_control_on()、clock_control_configure() 和 get_rate()。

探讨 SoC 开发者在移植过程中必须做出的实际决策：启动时应该在设备树中描述哪些信息，哪些工作应该留给运行时处理（例如电源管理），以及一些常见错误——包括单元格（cells）配置错误、混淆时钟门控（gates）与时钟多路复用器（muxes），以及在设备树中对硬件进行过度建模。

展望 Zephyr 的未来发展方向：有关**时钟管理子系统（Clock Management Subsystem）**的 RFC 提案，计划引入更丰富的时钟树结构和预定义时钟状态，使软件中的时钟描述更加贴近芯片实际的硬件连接方式。

Demystifying Pinctrl: Pin Multiplexing in Zephyr - Roy Jamil, Ac6^[20]

通俗讲解 Zephyr 引脚复用（Pinctrl）模型、各厂商策略与调试方法。

• 设备节点通过 pinctrl-N + pinctrl-names 声明引脚状态，驱动调用 pinctrl_apply_state() 切换。
• 配置分散在 4 层（SoC dtsi → HAL → 板级 → 应用 overlay），最终在 zephyr.dts 中看到全貌。
• 厂商策略各异但设备侧写法统一（STM32 点菜单 / NXP 自己写组 / i.MX 预制菜）。
• Zephyr 不检查引脚冲突，「编译通过不等于引脚正常工作」；给出 6 步调试清单，并演示 Devicetree Manager 可视化工具。

05 网络、无线连接与通信协议 x7

网络子系统、网络缓冲区、确定性网络、Matter、无线 PHY API、机器人通信与 DALI。

Network Subsystem Status and Overview - Jukka Rissanen, Nordic Semiconductor^[21]

Zephyr 网络子系统自 v4.0 以来的状态总览与演进。

• 规模：v4.0 以来 4828 次提交、465 位作者；网络代码量增长 65%，v4.5 单版本 +98000 行（超 1/3 是测试）。
• 新传输协议：WireGuard（v4.4）、QUIC（v4.5，支撑 HTTP/3）、SSH（v4.5 原生 SSH-2）。
• 协议栈：IPv4 路由转发与 NAT、IPv6 路由器角色、TCP SACK；v4.5 UDP 吞吐 +10%、TCP +18%。
• 测试升级：基于 TTCN-3 的协议一致性测试套件在 native_sim 上夜间 CI 执行，已修复多个 RFC 偏差。
• Wi-Fi：hostap 2.12（Wi-Fi 7 EHT、企业级认证、漫游、AP 模式），驱动族 8→16。

From TTEthernet To TSN on Zephyr: What Space Systems Teach Us About Deterministic Networking - Yasushi Shoji, Space Cubics Inc.^[22]

演讲者介绍 TSN 对 Zephyr 的重要性，为什么 Zephyr 不能简单地复制 Linux 工具，以及支持 TSN 的终端还存在哪些设计问题。

基于演讲者在 TTEthernet、Zephyr、micro-ROS 和空间 OBC 开发方面的经验，探讨 Zephyr 上的 TSN 应该发展成什么样子。TSN 并非单一功能：流量整形、调度传输、冗余、监管、配置、时间同步和硬件支持都至关重要。Linux 已经围绕 tc 和 linuxptp 等用户空间工具构建了成熟的 TSN 运维模型。Zephyr 没有 Linux 风格的用户空间，因此 TSN 需要 Zephyr 原生 API、shell 命令、示例、诊断工具和管理接口。

Zephyr Network Buffers - Johan Hedberg, Silicon Labs^[23]

Zephyr 网络缓冲区（net_buf）的起源、设计与十一年经验教训。

• 2015 年借鉴 Linux sk_buff 模型（reserve/push/pull/clone），从蓝牙 HCI 起家，现为约 50 个 API 头文件的公共类型。
• 四类池（FIXED/VAR/VAR_ALIGN/HEAP）覆盖确定性、变长、DMA 对齐、零拷贝需求。
• 六大常见错误：所有权丢失（双 unref 断言）、API 所有权转移要显式、SMP 下「一次只有一个写者」、headroom 误用、池要按数据流拆分、user_data 需约定。
• 4.5 新增原子引用计数、harden 配置；未来讨论突破 64KB 限制。

Enabling Matter on Zephyr - Aksel Mellbye, Silicon Labs^[24]

在 Zephyr 上启用 Matter 智能家居协议——集成方式、改进与路线图。

Matter 运行于 IPv6（Thread/Wi-Fi/Ethernet，BLE 配网），Zephyr 平台层源自 Nordic 2020 年工作，现被 NXP 和 Silicon Labs 使用。构建通过 Zephyr 模块以 ExternalProject 封装 GN/Ninja，最终链接 libCHIP.a；2026 年 3 月 TSC RFC 确定继续走「外部项目」路线。

关键改进：与 Mbed TLS 上游合作拆分 PSA Crypto 驱动分发，Zephyr 4.5 将支持 NXP/ST/Sil Labs 硬件加密加速，大幅缩短配网时间。

愿景：submanifests/matter.yaml + west update + west build 三步构建；推出不依赖 ZAP 的 all-devices-app 通用示例。

A Generic RF PHY Driver API for Proprietary Protocols in Zephyr - Sean Lyons & David Fosca Gamarra, Texas Instruments^[25]

为 Zephyr 新增 prop_rf 模块——面向私有无线协议的通用 RF PHY 驱动 API。

• 私有 sub-1GHz/2.4GHz 市场庞大，但 Zephyr 缺少私有协议抽象；prop_rf 严格限定物理层，链路层交给应用。
• 分层可配置：设备树默认 → 板级 overlay → 每操作参数 → 可选操作（get_caps 门控）→ 厂商扩展。
• 已实现 ti_cc23x0 和 ti_cc140x_trx 两个后端，提供 shell 命令与收发/CW 测试示例；RFC 已开放（issue #119337）。

Zenbedded: Bringing Ros2_control Closer To the Embedded World - Christoph Froehlich, AIT Austrian Institute of Technology GmbH^[26]

Zenbedded 项目——Zephyr + Zenoh 把 ros2_control 带入 MCU 世界。

• 用 Zenoh（含面向 MCU 的 Zenoh-Pico）作为统一传输层，MCU 直连 ROS 2 网络，无需 agent，最小开销 5 字节。
• 「一应用、两序列化」：Tier 1 标准 ROS 2 CDR（互操作）+ Tier 2 紧凑打包二进制（性能）；提供 zenbedded_rcl 嵌入式客户端库。
• 基准：native_sim 上 Tier 1 约 450 Hz / Tier 2 约 1250 Hz；ESP32 真机 Tier 1 约 140 Hz。
• 演示 Furuta 倒立摆（ESP32-S3，400 Hz 控制线程）

From Specification To Merge: Implementing a Standards-Compliant DALI Driver for Zephyr - Sven Hädrich, sevenlab engineering GmbH^[27]

为 Zephyr 实现符合 IEC 62386 标准的 DALI 灯光控制驱动。

DALI 物理层为双线总线、1200 bps 曼彻斯特编码，时序要求苛刻（416.7 ± 16.7 µs），使用 PWM/捕获计数器等硬件外设完成时间关键部分。驱动 API 经多轮迭代，2025 年 4 月提交 PR #88128 后最终合并；后续增加总线碰撞检测、更多平台支持。

06 外设、传感器、USB、音频与工业 I/O x5

USB 主机/设备、传感器固件、音频输出、工业 I/O 统一接口等外设功能。

USB Development and Testing on Native Simulator - Johann Fischer, Nordic Semiconductor^[28]

在 native_sim 原生模拟器上进行 USB 开发与测试。

USB 主机/设备栈与驱动 API 清晰地分离；在事务/传输级别（而非信号级别）模拟 USB，简单且快速。虚拟 UHC（含 root hub）+ 虚拟 UDC + UVB 虚拟总线消息机制；v4.5 将带来主机 hub 支持。USB/IP 协议让 Linux 主机直接使用 Zephyr 模拟器中导出的 USB 设备（URB 序列化走 TCP/IP）。

Evolving Zephyr USB Host Stack: Enabling UVC, CDC-ECM and Hub With Real-World Lessons - Mark Wang, NXP Semiconductors^[29]

Zephyr USB host stack 演进

• host 比 device 难在「检测、识别、驱动、移除」四步反应；栈分层：应用 → 类驱动 → USBH core → UHC API → 控制器驱动。
• 缺口 1/2 已入 main：动态类匹配（支持复合设备）、配置选择（依次尝试到能绑定类驱动的配置）。
• 缺口 3/4 审查中：pipe/endpoint 资源管理、移除生命周期（removed() 回调后不得再触碰设备对象）。
• class 支持：UVC、HUB 已入 main；CDC-ECM/ACM、Audio、MSC、HID 等在审查 PR 中；演示 FRDM-MCXN947 作 host 经 hub 连摄像头与网卡。

From Zero Hardware To Production: High-Performance Sensors With Zephyr - Jan Germer, Fluke Deutschland GmbH^[30]

分享基于 Zephyr RTOS 为工业对准工具开发多平台传感器固件过程中积累的实践经验。如何在严格的时间约束下实现确定性的事件处理，以及如何利用 DMA 驱动的 ADC 数据采集流水线，实现无需 CPU 持续参与的数据采集。了解如何设计具有良好扩展性的 Zephyr 固件架构、如何在缺乏实际硬件的情况下加速开发，以及如何更有把握地构建高性能嵌入式系统。

Playing Audio on a SoC DAC Output With Zephyr - Eve Redero, Redero Tech & Ugo Marchand, CloudExMachina^[31]

分享实现音频输出所需的几个关键要素：

• DAC：介绍 DAC 的工作原理，以及它与 PWM 音频输出和 I²S 外设之间的区别。
• DMA——DAC 的最佳搭档：讲解如何利用 DMA 实现连续、稳定的数据传输，避免音频播放过程中出现数据中断或丢失。
• 借助跟踪机制进行快速实时调试：介绍如何利用 tracing 快速定位问题，同时满足实时性要求。

结合 Zephyr 的 Codec 子系统，探讨具体的实现方式。采用 STM32F7 系列和 ATSAM3X8E 进行演示。

Libiio on Zephyr: A Unified API for Industrial I/O Across Linux and RTOS Targets - Maureen Helm & Pete Johanson, Analog Devices^[32]

libiio 是由 Analog Devices 开发的开源 C 语言库，用于与工业输入/输出（Industrial I/O，IIO）设备进行交互，包括 ADC（模数转换器）、DAC（数模转换器）、IMU（惯性测量单元）、射频收发器、温度传感器等。它为主机端工具提供了底层支持，包括 Scopy、pyadi-iio 和 MATLAB。这些工具都可以通过网络、串口或 USB 等传输方式连接到目标设备。

该演讲介绍 libiio 移植到 Zephyr 的整体架构与具体实现机制。重点内容如下：

• 外部后端与 Zephyr 设备模型的集成：libiio 的外部后端如何与 Zephyr 设备模型对接，使实现 IIO 设备驱动 API 的驱动程序，作为标准的 IIO 设备被识别和使用。
• 内置桥接驱动：介绍如何通过桥接驱动，将 Zephyr ADC、DAC 或传感器设备封装为 IIO 设备，接入 IIO 生态系统。
• 与 Zephyr 构建系统的集成：讲解该模块利用 Kconfig、设备树（Devicetree）和 snippets 机制进行配置，应用程序只需进行少量的修改，就能启用 libiio。

07 测试自动化、仿真与硬件 CI x4

native_sim、测试替身、硬件信号路由，以及跨地域硬件持续集成。

No Board, No Problem: Testing Zephyr Applications With Native_sim - Marco Widmer, bytes at work AG^[33]

分享在对多个真实应用项目进行结构设计、测试和调试的过程中积累的经验，内容包括：

• native_sim 的执行模型：如何处理时间。
• 如何模拟硬件：包括模拟驱动程序（Fake Drivers）、虚拟蓝牙控制器、网络、通过 PTY 实现的 UART，以及各类仿真器。
• 利用这些基础功能可以实现的应用示例：
• 通过 BLE 与 Android 模拟器建立连接。
• 使用 Cucumber 测试框架编写 Zephyr 测试。
• native_sim 相关工具链：包括 Twister、内存与未定义行为检测工具（Sanitizers）、GDB 调试器以及代码覆盖率工具。
• 通过 pytest 测试框架集成外部二进制程序：将外部二进制程序接入 Twister。
• 面向可测试性的设计：将业务逻辑与依赖硬件的软件单元分离。
• native_sim 无法满足需求时的替代方案：在 QEMU 仿真环境或真实硬件上运行测试。

本次演讲旨在全面介绍 native_sim 所能实现的各种功能，希望借此激发新思路，探索如何在完全不接触真实硬件的情况下测试代码。

Fake Drivers: A Practical Guide To Zephyr Test Doubles - Henrik Brix Andersen, Vestas Wind Systems A/S^[34]

基于 FFF 框架的「假驱动」（fake drivers）实现无需硬件的单元测试。

• 测试替身模式解耦被测单元与硬件依赖；假驱动基于 Fake Function Framework（FFF），支持参数捕获、返回值设置、调用历史检查。
• 假驱动完整解剖：devicetree binding + Kconfig + CMake + FFF 宏 + 设备 API 绑定。
• 上游已有 fake-can、fake-eeprom、fake-leds、fake-pwm、fake-rtc、fake-regulator 等可用。
• 常见问题：FFF 全局变量定义、用 ZTEST_RULE 重置状态、未初始化内存用 custom delegate。

Stop Rewiring: Scale Embedded Hardware Testing - Franklin Cooper, Texas Instruments^[35]

本次演讲介绍一个开源测试框架。该框架使用一块价格低廉的 FPGA 开发板作为可编程信号路由平台。FPGA 位于被测设备与测试环境中的其他设备之间，负责将引脚信号路由到回环连接、其他外设、其他开发板或测试工具。

该框架与软件平台无关，可用于 Zephyr、Linux、裸机环境以及芯片厂商 SDK 的测试。测试用例只需声明所需的连接关系，元数据则描述 FPGA 与被测设备之间的实际接线方式。随后，框架会自动为每个测试用例生成相应的 Verilog 代码，调用开源 FPGA 工具链，并将生成的设计烧录到 FPGA 中。

演示展示整个框架的工作方式，以及如何在个人工作台、实验室或持续集成（CI）环境中复现这套测试方案。

Scaling Zephyr Hardware CI Across Continents - Anıl Özrenk, Analog Devices^[36]

跨区域扩展 Zephyr 硬件 CI——ADI 统一测试分布多国的 30+ 设备。

• 挑战：7 个团队、多国 30+ 设备、部分硬件依赖 Windows 工具、「板子半夜挂掉且 5000 公里外没人能处理」。
• 统一方案：每台 runner 一个 YAML 配置 + 三个可复用 GitHub Actions workflow + 容器化工具链。
• 「Shift left」：每次 PR 同时在虚拟平台、SoC 仿真、FPGA、真实硅片上测试；另有 footprint 回归流水线。
• 经验：远程板子默认不可靠，连接硬件前先定义团队间技术接口，把板卡健康度当一等信号。

通过该分享，可以了解如何构建跨国家、跨操作系统、跨团队的 Zephyr 自动化测试体系，让真实硬件测试成为日常开发流程的一部分，而不只是发布前才执行的验证步骤。

08 调试、可观测性、性能分析与可靠性 x6

运行时观测、性能计数器、AI 应用跟踪、构建性能、栈溢出预警和崩溃转储。

ZView: Non-Intrusive Runtime Observability for Zephyr - Paulo Santos, EDGE-UFAL^[37]

ZView 通过调试口非侵入式读取 Zephyr 运行时状态的 TUI 观测工具。

• 沿用「虚拟屏幕读内存」技巧，通过 SWD 轮询内核线程链表实现实时观测，目标端零代码改动。
• 功能：线程 CPU 占比、栈水位、负载曲线、堆碎片化热图、内核对象状态与等待队列。
• 开销极小：任意构建 +0 开销；启用模块仅 +640 B flash / +440 B RAM；只读不暂停目标。
• 与 trace 工具互补（非 trace）；未来计划 MCP 服务器让 AI agent 直接读取开发板实时状态。

Measuring What Matters: Introducing Hardware Performance Counters in Zephyr RTOS - Kedareswara Rao Appana, AMD^[38]

为 Zephyr 引入硬件性能计数器（PMU）可移植 API，实现近零开销性能测量。

• 硬件 PMU 计数器近乎零开销，回答「为什么慢」而非只有「多慢」；新 PR #107016 提供架构无关 include/zephyr/pmu.h。
• 首个后端 ARMv8-A PMUv3；已在 Versal NET（4× Cortex-A78）验证。
• 新增基准测试可测量上下文切换、IRQ 延迟、缓存行为、分支预测，并可在 CI 中捕获性能回退。
• PC 采样与 shell 命令（PR #119581）、类 Linux perf stat 的统一性能子系统（RFC #119608）。

Amalgamation - Tom Burdick, Infineon Technologies^[39]

无文档

Amalgamation（源码合并）是一种构建策略，SQLite 等项目会使用这种方法将多个 C 源文件合并为一个源文件。这样做可以让编译器能够更全面地了解整个程序，从而提升性能。SQLite 提到采用这种方式可以带来 5%–10% 的净性能提升。

该演讲探讨如果将这种技术应用于 Zephyr 的部分模块，是否会带来性能收益；如果可以，收益来自哪里、在哪些模块中最明显，这种方法又需要付出哪些代价和权衡。

In-depth AI Application Analysis in Zephyr with Zephelin and the Instrumentation Subsystem - Greg Latosinski, Antmicro^[40]

Zephelin 工具与 Zephyr 新增 Instrumentation 子系统，用于 AI 应用运行时性能追踪。

• Zephelin 采集追踪（CTF）、堆/CPU/内存/温度等指标；新 Instrumentation 子系统基于 GCC -finstrument-functions 函数级插桩。
• 自动追踪 AI 运行时事件：TFLite Micro 逐层耗时、microTVM 按图定义跟踪模型。
• 提供 Web Trace Viewer、zpl-live-server 实时预览、VSCode 扩展；已发布 Zephelin 1.0.0。

Let Your CI Catch Your Stack Overflows, Before They Hit Your Testing or the Field - Paul Würtz, Independent^[41]

基于 ELF 的静态固件分析，调用图构建与线程栈用量估算（pexplorer + sELFperf）。

• 解析 ELF/汇编获取函数栈用量与调用关系，或利用 GCC -fstack-usage/-fcallgraph-info，构建调用树得到线程最坏情况栈需求。
• 对比 puncover、avstack.pl 等四大工具差异；pexplorer 为 Go+Svelte 实现，支持多目标。
• CI 集成：在 MR/PR 中评论各目标板栈用量对比，检测到栈溢出使流水线失败（CANnectivity 项目实例）。
• 通过解析 _static_thread_data_area 与 device struct 补全间接调用；相关 RFC 已开在 zephyr#112163。

Crash Dumps Without Cables: Live Coredump Capture Over UDP/Ethernet in Zephyr RTOS - Kedareswara Rao Appana, AMD^[42]

通过 UDP/Ethernet 流式输出 Zephyr coredump（已合并 PR #108410）。

• 现场密封设备崩溃时无 JTAG/UART 访问。
• 「垂死系统中的网络发送」（中断屏蔽、不能阻塞、不能分配内存），四个技巧：小中断窗口、非阻塞 sendto + 有界重试、启动时预创建 socket、自定义 ZCDU 帧主机端乱序重组。
• 一个 Kconfig 开关；已在 AMD Versal NET（Cortex-A78 4 核 SMP）验证。
• 局限：若以太网本身崩溃则无法保证捕获，建议与 Flash 后端配合。

往年 ZDS

Zephyr 2025开发者大会演讲文档概览

Zephyr 2024开发者大会演讲文档概览

Zephyr 2023开发者大会演讲文档概览

Zephyr 2022开发者大会演讲文档概览

Zephyr 2021开发者大会演讲文档概览

参考资料