各位嵌入式开发者朋友大家好。在物联网设备、可穿戴硬件和智能工业终端层出不穷的今天选择一个合适的实时操作系统RTOS往往决定了项目的开发效率、可维护性和长期演进能力。提到 RTOS很多人首先想到的是 FreeRTOS它资料多、上手快、生态成熟。但如果你正在做一个功能复杂、硬件平台多样、需要长期迭代的产品Zephyr 很可能会成为更值得投入的方向。本文不是一篇简单的“Zephyr 介绍”而是一份完整的入门到进阶实操笔记。我会从 Zephyr 的核心设计理念讲起带大家一步步完成环境搭建、Kconfig 配置解析、多架构编译最后用一张深度对比表格拆解 Zephyr 与 FreeRTOS 的选型逻辑。无论你是刚接触嵌入式的新手还是已经在用 FreeRTOS、想评估新方案的老手这篇文章都会给你提供可落地的参考。接下来让我们正式开始。1. Zephyr 是什么它解决了什么问题1.1 从物联网碎片化看 Zephyr 的诞生背景在深入技术细节之前先聊一个宏观问题为什么我们需要 Zephyr传统 RTOS 的世界里每个 MCU 厂商都有自己的私有 SDK 和协议栈。比如你使用某家厂商的蓝牙 SoC那你就被绑定在该厂商的 IDE、协议栈 API 和示例代码里。换一个芯片厂商哪怕换同一家厂商的不同系列芯片原来的驱动代码基本都要重写。这种碎片化给开发团队带来了巨大的学习成本与迁移成本。Zephyr 是由 Linux 基金会维护的开源实时操作系统项目它的目标非常明确做一个面向物联网和嵌入式设备的、跨架构、可裁剪、模块化的通用 RTOS。你可以把 Zephyr 理解为嵌入式领域的“Linux 式体验”——它提供了一套统一的设备驱动模型、统一的构建系统、统一的应用层 API让同一套应用程序代码可以在 ARM、RISC-V、x86、Xtensa 等多种 CPU 架构上编译运行。1.2 Zephyr 的核心特性Zephyr 不是又一个“能跑任务的 RTOS”它从设计之初就考虑了现代物联网产品的真实需求。下面是它的几个核心特性可裁剪的内核Kernel通过 Kconfig 图形化配置工具你可以精确控制哪些内核对象、系统调用、驱动模块被编译进固件。一个最小系统可以做到几 KB 级别满足 MCU 资源限制。强大的设备树Device Tree机制Zephyr 使用设备树文件.dts/.dtsi来描述硬件资源解决了跨平台硬件差异问题。应用程序代码通过设备树 API 访问外设而不必关心底层寄存器地址。统一的驱动模型Zephyr 定义了标准化的驱动接口比如 GPIO、UART、I2C、SPI、Flash、Sensor 等。相同的外设接口在不同芯片上的 API 是一致的这对代码复用非常有帮助。原生支持蓝牙、OTA、低功耗管理蓝牙协议栈和 OTA 升级机制不是“第三方移植”而是 Zephyr 项目的主要组成模块。这省去了大量集成工作。子系统生态丰富文件系统LittleFS、NVS、网络协议栈IPv4/IPv6、CoAP、MQTT、日志系统、Shell、电源管理等都已内置。1.3 Zephyr 适合什么场景理解了特性之后你可能会问哪些项目适合选 Zephyr根据实际项目经验以下几类场景比较适合场景类型说明多产品线开发同一团队开发多款基于不同 MCU 的产品希望通过统一 OS 层降低维护成本蓝牙低功耗产品智能手表、传感器标签、HID 设备等Zephyr 的 BLE 协议栈集成度高需要协议栈的场景使用 Thread、Matter、Zigbee 等新通信协议Zephyr 是这些协议的主阵地长期维护的产品社区活跃、版本迭代规范代码长期维护的可持续性强学习嵌入式架构想系统学习设备树、驱动架构、现代构建系统的开发者当然Zephyr 的学习曲线比 FreeRTOS 陡峭这一点是不能回避的。它不是一个“30 分钟跑通一个任务”的入门玩具而是一个需要系统性学习的开发框架。2. 环境准备与版本说明在开始写代码之前先搭建一套可用的开发环境。Zephyr 的构建系统依赖 Python、CMake、Ninja 和交叉编译工具链整体链路比普通单片机工程复杂一些。2.1 操作系统与工具版本为了演示环境搭建过程本文以 Ubuntu 22.04 LTS 为例进行说明。这套流程在 Windows配合 WSL2和 macOS 上思路相同只是包管理器的差异。如果你在 Windows 上开发强烈建议使用 WSL2因为 Zephyr 的脚本和工具链在 Linux 环境下兼容性最好。工具版本要求如下工具最低要求说明Python3.8Zephyr 的构建脚本基于 PythonCMake3.20构建系统核心Ninja最近版本即可高性能构建工具west对应 Zephyr 版本Zephyr 元工具负责拉取源码与编译注意Zephyr 对 Python 版本的依赖是硬性的如果你的系统默认 Python 版本过低建议先升级或使用虚拟环境不要直接改系统的软链接。2.2 正式安装核心依赖先把系统的底层依赖安装好sudo apt update sudo apt upgrade -y sudo apt install -y \ git cmake ninja-build gperf \ ccache dfu-util device-tree-compiler wget \ python3-dev python3-pip python3-setuptools \ python3-tk python3-wheel xz-utils file \ make gcc gcc-multilib g-multilib libsdl2-dev libmagic1安装完系统依赖后我们来安装 Python 侧的依赖# 升级 pip python3 -m pip install --upgrade pip # 安装 west pip3 install west安装完成后我们在 HOME 目录创建一个 Zephyr 工作区并拉取源码。由于 Zephyr 由多个仓库组成zephyr 主仓库、模块仓库、工具仓库等west会自动管理这些仓库的版本关系。mkdir zephyr_workspace cd zephyr_workspace west init zephyrproject cd zephyrproject west updatewest update这一步会从 GitHub 拉取 Zephyr 及其所有子模块包括 cmsis、hal_stm32、hal_nxp、hal_nordic 等。这个过程受网络环境影响较大建议采用合适的网络方式完成后继续开发代码无法获取会导致后续所有编译失败。2.3 安装交叉编译工具链Zephyr 官方推荐使用 Zephyr SDK 来实现多架构交叉编译。SDK 提供了一套完整的工具链集合包括 gcc、binutils、gdb 以及所有支持的芯片架构的交叉编译版本。cd ~ # 下载 Zephyr SDK 安装包这里以最新版本为例 wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5-1/zephyr-sdk-0.16.5-1_linux-x86_64.tar.xz # 解压 tar xvf zephyr-sdk-0.16.5-1_linux-x86_64.tar.xz # 进入目录执行安装脚本 cd zephyr-sdk-0.16.5-1 ./setup.sh安装脚本会提示你是否将 SDK 加入环境变量选择 yes 即可。同时还需要安装 udev 规则这对以后使用 OpenOCD、JLink 等调试工具很有帮助sudo cp ~/zephyr-sdk-0.16.5-1/sysroots/x86_64-pokysdk-linux/usr/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d/ sudo udevadm control --reload-rules版本提示这里给出的 SDK 路径是当前较稳定的版本实际使用时请根据 Zephyr 文档获取与你的 Zephyr 版本匹配的 SDK 版本避免版本不匹配导致链接错误。2.4 环境变量验证环境变量写入后建议重新打开终端或手动执行source ~/.bashrc # 验证 west 是否可用 west --version # 验证工具链 cmake --version ninja --version如果你的west命令找不到可能是 Python 的 scripts 目录没有加入 PATH把export PATH~/.local/bin:$PATH加入.bashrc再试一次。至此Zephyr 环境搭建已经完成。这张“地基”打好了后面的编译、烧录、调试才会顺利。3. Zephyr 构建系统与 Kconfig 机制深度解析经常有小伙伴问Zephyr 的构建系统到底怎么运作的为什么一个prj.conf文件就能决定整个系统的功能开关要回答这个问题我们要从两个工具说起CMake 和 Kconfig。3.1 构建系统整体流程Zephyr 基于 CMake 构建但west build命令在背后做了大量封装。一条完整的构建命令west build -b board_name -p -d build application_dir参数说明-b board_name指定目标开发板例如nrf52840dk_nrf52840、qemu_cortex_m3。-pclean每次都执行干净的构建排除旧编译产物干扰。-d build输出目录默认是 application 目录下的build。application_dir应用代码目录包含CMakeLists.txt、prj.conf和src/main.c。执行构建时Zephyr 会按以下顺序处理读取目标开发板的底层定义默认配置文件、设备树文件。生成build/Kconfig把所有.config文件合并。调用 Kconfiglib 解析配置生成autoconf.h头文件。根据配置生成 Makefile 并执行编译、链接。输出.elf、.hex、.bin和.map文件。这里最关键的是第二步和第三步——Kconfig 机制。3.2 Kconfig 是什么Kconfig 是内核社区为了解决“如何灵活裁剪系统功能”问题而设计的一种配置语言。Zephyr 在开发早期就沿用了这一设计现在已经成为 Zephyr 的灵魂之一。每一个 Zephyr 模块都有一个Kconfig文件里面定义了该模块支持哪些配置选项。拿一个虚拟的传感器驱动举例# 文件路径drivers/sensor/my_sensor/Kconfig config MY_SENSOR bool My Sensor Driver depends on I2C help Enable My Sensor driver for I2C-based sensor. if MY_SENSOR config MY_SENSOR_TRIGGER bool Enable trigger support depends on GPIO default y help Enable sensor threshold trigger via GPIO interrupt. endif # MY_SENSOR这里有几个关键词bool配置类型表示这是一个布尔开关值为 y编译进固件或 n不编译。depends on依赖条件只有在满足I2C启用时该选项才可见。help帮助信息说明这个配置的用途。default y默认值用户不手动修改时生效。3.3 prj.conf 与 menuconfig 配置用户侧配置通过prj.conf文件修改。在应用目录下创建一个prj.conf# 项目自身的配置 CONFIG_MY_SENSORy CONFIG_MY_SENSOR_TRIGGERy CONFIG_LOGy CONFIG_GPIOy CONFIG_I2Cy注意在prj.conf中写配置项时前缀是CONFIG_而 Kconfig 文件里写 TITLE 参数时不需要前缀。这个细节很容易搞混。如果配置项太多或者你想看看哪些配置可选可以用交互式界面west build -b board_name application_dir -t menuconfigmenuconfig是一个字符界面的配置菜单可以展开每个模块查看选项、功能说明和依赖关系。修改后保存Zephyr 会重新生成autoconf.h并编译。3.4 Workbench for Zephyr 与 Kconfig 可视化配置前面我们讲的 Kconfig 配置都是在命令行环境下进行的。有没有更直观的方式这就不得不提Workbench for Zephyr。Workbench for Zephyr 是多种 IDE 插件和图形化工具的总称市面上常见的是基于 VS Code 的扩展集例如 Nordic 的 nRF Connect for VS Code 就深度集成了 Zephyr 开发流程。它提供了以下能力面向工程视图的 Kconfig 图形配置界面不需要记忆格子配置项直接勾选开关即可。当前配置项搜索与依赖关系高亮比如你搜索BLE它能列出所有与蓝牙相关的配置项并标明哪些已经启用、哪些因依赖未满足而隐藏。设备树可视化预览可以直接看到当前开发板启用了哪些外设节点。一键编译、烧录、调试底层调用 west但 UI 层非常友好。在 Workbench 中修改 Kconfig 配置后它的本质和手工修改prj.conf是一样的最终都会生成mconf配置文件并在编译时生效。区别只是操作体验所以即使你不用这个工具理解了 Kconfig 的底层逻辑也不会影响后续开发。4. Zephyr vs FreeRTOS 深度对比2026 年嵌入式项目选型指南作为一个长期关注 RTOS 选型的工程师我经常被问到同一个问题“Zephyr 和 FreeRTOS到底应该选哪个”这个问题没有一个放之四海而皆准的答案。为了帮大家建立清晰的判断框架下面我从多个维度做一次深度对比。4.1 对比表格Zephyr vs FreeRTOS对比项ZephyrFreeRTOS项目维护方Linux 基金会Amazon Web ServicesAWS许可证Apache 2.0MIT内核类型抢占式 协作式支持多优先级抢占式 协作式支持多优先级最小内核大小几 KB裁剪后约 4-9 KB设备驱动模型标准化驱动框架基于设备树无强制标准通常由厂商提供硬件描述方式设备树Device Tree直接代码配置或 Board Support Package协议栈支持原生 BLE、Thread、Matter、Zigbee、Wi-Fi以协作方案为主如 NimBLE、ESP-IDF文件系统内置 LittleFS、NVS、FCB需自行移植或搭配 SDKOTA 升级内置 MCUboot 深度集成需自行设计网络协议原生支持 IPv4/IPv6、MQTT、CoAP、LwM2M可用第三方库但集成成本高支持 CPU 架构ARMCortex-A/R/M、RISC-V、x86、Xtensa、ARCARM、RISC-V、Xtensa、MIPS 等平台相关开发工具链west CMake Ninja Kconfig各厂商 IDE 或 Makefile/CMake学习曲线陡峭设备树、Kconfig、模块化平缓任务/队列/信号量即可上手社区活跃度高Intel/NXP/Nordic/ST 都深度参与极高AWS 背书且生态庞大商业支持生态提供商如 Nordic、NXP提供支持AWS 认证与商业咨询服务4.2 什么时候继续选 FreeRTOS不要因为 Zephyr 功能强大就盲目切换。FreeRTOS 在以下场景里依然是非常合理的选项当前项目只需一个简单任务调度器不需要复杂协议栈。团队成员对 FreeRTOS API 非常熟悉时间急迫要求快速交付。项目使用特定厂商的 SDK如 STM32CubeMX、ESP-IDF这些 SDK 内部已经封装好 FreeRTOS原生的 Zephyr 支持反而不一定顺畅。MCU 资源极有限RAM 8 KBZephyr 的设备树和模块机制此时有冗余压力。产品只需要非常简单的裸机 事件轮询逻辑未来也没有跨平台扩展计划。在这些场景里FreeRTOS 的“轻”和“直接”就是优势。4.3 什么时候应该转向 Zephyr反过来如果你有以下需求Zephyr 的价值就很明显同一套代码需要在多家芯片平台上复用减少厂商绑定风险。产品需要完整的 BLE、Wi-Fi、Matter、Thread 多协议栈Zephyr 原生集成度高。产品需要可靠的 OTA 升级链路Zephyr MCUboot 是很成熟的组合。团队愿意投入时间学习现代嵌入式开发方法设备树、Kconfig、west 工作流。产品生命周期长希望依托活跃社区持续获得安全更新与协议栈升级。4.4 选型决策实操建议在实际项目立项阶段我的经验是不要只比较功能列表要拿两个系统各自写一个最小外设驱动用例分别在目标开发板上跑通对比实际烧录体积、启动时间、RAM 占用和维护成本。具体可以按以下步骤走列出项目的硬性需求协议栈、外设数量、OTA、功耗管理。在两款 RTOS 上分别实现一个相同的“采集传感器数据并通过 BLE 上报”的 Demo。测量编译后固件大小和运行时 RAM 占用。评估团队学习成本从拿到完整工程到能独立新增一个驱动各需要几天。最后再结合产品生命周期选定最终方案。这一套走下来比看任何对比文章都直观。5. 完整实战案例从零构建一个 GPIO 传感器读取项目前面已经完成了环境搭建和理论分析下面进入实际动手环节。我们用 QEMU 模拟器跑一个最小的 Zephyr 项目实现 GPIO 输出控制“虚拟 LED”闪烁并通过日志系统打印运行状态。5.1 创建项目结构在zephyr_workspace下创建我们的应用目录cd ~/zephyr_workspace mkdir my_first_app cd my_first_app mkdir src最终目录结构如下my_first_app/ ├── CMakeLists.txt ├── prj.conf └── src/ └── main.c5.2 编写 CMakeLists.txtZephyr 应用需要使用find_package引入 Zephyr 构建框架# 文件路径my_first_app/CMakeLists.txt cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project(my_first_app) target_sources(app PRIVATE src/main.c)关键点find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})用于定位 Zephyr 根目录。project()定义应用名称。target_sources(app PRIVATE src/main.c)把源文件加入构建目标。5.3 编写 prj.conf 配置本示例需要用到 GPIO 和日志功能# 文件路径my_first_app/prj.conf CONFIG_GPIOy CONFIG_LOGy CONFIG_LOG_MODE_IMMEDIATEyCONFIG_GPIOy启用 GPIO 子系统日志配置让系统运行信息可以直接打印到控制台。5.4 编写 main.c 主程序下面是核心代码。这个示例的逻辑是初始化 GPIO 引脚然后在主循环里让引脚电平来回翻转模拟 LED 闪烁// 文件路径my_first_app/src/main.c #include zephyr/kernel.h #include zephyr/device.h #include zephyr/drivers/gpio.h #include zephyr/logging/log.h LOG_MODULE_REGISTER(main, LOG_LEVEL_INF); /* 定义一个开发板无关的 LED 节点可在设备树中覆盖 */ #define LED0_NODE DT_ALIAS(led0) static const struct gpio_dt_spec led GPIO_DT_SPEC_GET(LED0_NODE, gpios); int main(void) { int ret; if (!device_is_ready(led.port)) { LOG_ERR(LED GPIO controller device is not ready); return -1; } ret gpio_pin_configure_dt(led, GPIO_OUTPUT_ACTIVE); if (ret 0) { LOG_ERR(Failed to configure LED pin (error %d), ret); return ret; } LOG_INF(LED GPIO configured successfully); while (1) { gpio_pin_toggle_dt(led); LOG_INF(LED toggled); k_msleep(1000); } return 0; }代码说明DT_ALIAS(led0)通过设备树别名获取 LED 节点这样同一份代码在不同开发板上可以复用。GPIO_DT_SPEC_GET获取 GPIO 控制器的描述符port 指针 pin 编号 配置标志。gpio_pin_configure_dt是 Zephyr 4.x 推荐的设备树友好 API避免手动传引脚号。主循环每秒翻转一次 GPIO 电平并打印日志。5.5 编译与运行现在开始编译。我们使用 QEMU 模拟器作为目标平台这样不需要真实开发板就能看到运行效果cd ~/zephyr_workspace/my_first_app west build -b qemu_cortex_m3 -p .编译成功后执行west build -t run预期输出截取关键部分*** Booting Zephyr OS build v3.5.0 *** [00:00:00.000,000] inf main: LED GPIO configured successfully [00:00:01.000,000] inf main: LED toggled [00:00:02.000,000] inf main: LED toggled ...按下CtrlA后按X可以退出 QEMU。5.6 换板实战编译到真实开发板如果你手上有一块常见的开发板比如nrf52840dk_nrf52840或stm32f429i_disc1只需要修改-b参数west build -b nrf52840dk_nrf52840 -p .Zephyr 的优势在这里就体现出来了——应用程序代码完全不变只是更换了目标板定义和对应的工具链构建系统会自动处理引脚映射和驱动差异。6. 常见问题与排查思路在实际开发中环境问题和编译问题往往占据了大量时间。我整理了几个高频问题并给出排查思路。问题现象常见原因解决思路west命令找不到Python 的 bin 目录未加入 PATH执行export PATH~/.local/bin:$PATH并写入.bashrcwest update拉取仓库超时GitHub 访问速度慢或网络不稳定配置代理、使用镜像仓库或使用西数云托管服务编译时报invalid argument或Permission deniedZephyr SDK 没有执行权限或 udev 规则未生效重新执行setup.sh并确保udevadm已加载规则链接阶段报arm-none-eabi-gcc: not foundZEPHYR_TOOLCHAIN_VARIANT 未正确设置检查环境变量确认 SDK 安装路径与setup.sh选择一致设备树节点led0未定义开发板 .dts 文件未定义 led0 别名使用west build -b board -t menuconfig检查或参考官方板级定义是否有该别名日志输出乱码或为空终端串口波特率不匹配确认终端使用 115200 波特率并检查 prj.conf 中日志等级配置另外如果你在west build之后修改了prj.conf但没有重新构建注意要加上-p参数进行干净构建避免旧的配置缓存影响新的编译结果west build -b qemu_cortex_m3 -p .7. 最佳实践与工程建议基于多个 Zephyr 项目的落地经验我整理了一些建议供你在实际开发中参考。7.1 版本管理与模块固定Zephyr 的代码库由多个仓库组成如果直接使用west update拉取最新版本很容易在某些更新点引入兼容性问题。建议在项目文档里明确记录west manifest的版本信息west update --narrow -f west manifest --freeze west.yml.lock这样团队里所有人拉取的都是完全一致的代码版本避免“我本地能编译你那边就报错”的问题。7.2 配置项分层管理不要把所有的配置都填写在主项目的prj.conf里。建议按模块拆分配置文件prj.conf应用核心配置。prj_board.conf按开发板覆盖的配置。app.overlay设备树覆盖层按板级声明外设连接。在CMakeLists.txt中可以用条件判断引入不同配置if(${BOARD} STREQUAL nrf52840dk_nrf52840) set(CONF_FILE prj.conf prj_nrf52840.conf) endif()这样配置更清晰也便于新增开发板时快速适配。7.3 日志与调试规范Zephyr 的日志系统是开发排查的重要手段但默认配置会占用较多 RAM。建议在产品化阶段调整日志等级CONFIG_LOGy CONFIG_LOG_DEFAULT_LEVEL2 CONFIG_LOG_MODE_DEFERREDyCONFIG_LOG_DEFAULT_LEVEL2只保留 INFO 及以上日志。CONFIG_LOG_MODE_DEFERREDy使用缓存模式降低中断上下文中的日志开销。正式发布时可以进一步关闭日志或只保留错误日志减小固件体积。7.4 设备树与硬件抽象思维很多从裸机或 FreeRTOS 转过来的开发者在 Zephyr 上最容易犯的错误是看到引脚号就直接写在代码里比如gpio_pin_configure(dev, 23, ...)。在 Zephyr 中请务必使用设备树节点或别名#define BUTTON_NODE DT_ALIAS(sw0) static const struct gpio_dt_spec button GPIO_DT_SPEC_GET(BUTTON_NODE, gpios);这样的好处是当硬件改版、引脚重映射时只需要修改设备树文件和 overlay而不需要改动 C 代码。产品维护成本大幅降低。7.5 安全与低功耗注意事项Zephyr 对低功耗和安全管理有很好的支持但需要开发者主动开启相应配置低功耗场景下开启CONFIG_PM_DEVICEy并在设备驱动中实现pm_action_callback确保外设进入低功耗状态。对安全关键产品利用 Zephyr 的用户空间Userspace机制隔离不可信驱动并使用 MPU 限制访问权限。在进行 Flash 擦写、OTA 切换等操作前务必在测试板上完整验证并保留固件备份。8. 总结与下一步学习路线写到这里整篇教程的主体内容就结束了。我们来回顾一下本次掌握的核心知识点Zephyr 是一个面向物联网的模块化实时操作系统生态由 Linux 基金会维护。Zephyr 环境搭建基于 west CMake NinjaSDK 提供了多架构交叉编译能力。Kconfig 和设备树是 Zephyr 的配置基石理解了它们就理解了 Zephyr 的“可移植性”。Zephyr 与 FreeRTOS 的选型取决于项目需求、团队能力与产品生命周期没有绝对答案。实操层面通过 QEMU 我们可以用最小的成本快速验证 Zephyr 应用开发流程。下一步建议按照这个顺序继续深入阅读官方文档的 Device Tree Guide尝试为一块新板卡编写设备树文件。学习 Zephyr 的驱动模型了解struct device和device_ready()的底层逻辑。动手移植一个简单的传感器驱动并接上日志系统。尝试使用 MCUboot 实现本地 OTA 升级。研究官方samples目录下蓝牙相关示例运行一个 BLE Peripheral 程序。Zephyr 的学习曲线确实不算平缓但只要你愿意投入时间它会回馈给你一套高效的、跨平台的嵌入式开发方法论。如果你在搭建过程中遇到问题欢迎在评论区带上完整报错信息与我交流我会定期查看并回复。也可以把本文收藏备用后续需要做 RTOS 选型或环境排错时可以直接查阅。祝你开发顺利我们下篇文章见。