FreeRTOS 和 Zephyr 怎么选？选型对比

大家好，我是杂烩君。

最近有粉丝朋友问：新项目到底上 FreeRTOS，还是直接上 Zephyr？

我的理解是，这不是新旧之争，也不是谁替代谁，而是两种工程路径：

FreeRTOS = 极简调度内核（毛坯房）；Zephyr = 一体化嵌入式平台（标准化模块化别墅）。

先给结论：

边界清楚、资源紧、团队已有成熟 MCU/Cube 经验，优先 FreeRTOS；多板复用、连接协议多、产品线要长期演进，且愿意为工程体系付学习成本，更适合 Zephyr。

下面先对齐两边都绕不开的 RTOS 共性，再分别看 FreeRTOS 和 Zephyr 整体架构。

1. RTOS 的共同底层逻辑

不管 FreeRTOS 还是 Zephyr，RTOS 最核心的任务都不是让程序变复杂，而是解决前后台系统在复杂项目里调度与解耦越来越难的问题。

前后台大家都很熟：前台是中断，后台是一个大 while(1)。项目一复杂，顺序轮询就开始互相拖累。

RTOS 做的第一件事，就是把它拆成可抢占的多任务，由调度器决定谁跑、谁等：

说明：

前台 ISR：快响应，只做清标志、读少量数据、通知任务后台若只有一个大循环：模块互相拖累，实时性靠“排班运气”RTOS：拆成可抢占任务，由调度器决定谁跑、谁等

每个任务看起来都像一个独立的 while(1)，但 CPU 只有一个或少数几个核心。下面几个基础概念，两边 RTOS 都绕不开：

说明：

任务状态：就绪 / 运行 / 阻塞 / 挂起，等事件时阻塞让出 CPU优先级：高优先级就绪可抢占低优先级Tick 与超时：系统节拍管延时与超时中断与任务：中断只做快响应，重业务放任务里同步对象与内存：队列 / 信号量 / 互斥锁，以及静态对象、内存池或堆的取舍

从这个角度看，FreeRTOS 和 Zephyr 的共同点是：它们都在解决多任务调度、实时响应、任务通信和资源管理问题。选型差异，主要不在“会不会调度”，而在平台层你要不要自己拼。

2. FreeRTOS 整体架构

FreeRTOS 官网：https://www.freertos.org/

FreeRTOS 的主角是 kernel，不是大而全操作系统。

使用 FreeRTOS 开发的项目，工程结构大概是这样：

说明：

应用任务层：sensor / control / comm / log 等任务FreeRTOS 内核对象：task、queue、semaphore、mutex、event group、timer 等portable 层：对接 Cortex-M、RISC-V、Xtensa 等架构的上下文切换再往下是芯片 SDK / HAL / BSP 与硬件本身

也就是说，FreeRTOS 很少规定我们必须怎么组织驱动、怎么描述板级资源、怎么管理协议栈依赖。它把最核心的调度和同步机制做好，然后把大量工程组织自由度留给我们。

这就是它轻的原因，也是它长期流行的原因。

2.1 调度器

调度器是 FreeRTOS 的心脏。

FreeRTOS 调度器围绕任务优先级工作：就绪、延时、阻塞与上下文切换，把实时性落实在短路径上。

FreeRTOS 调度器之前我们也有分享过：FreeRTOS调度器：抢占与轮转机制

简单总结如下：

说明：

任务由栈、TCB、优先级和状态组成调度路径短：就绪队列挑最高优先级，必要时做上下文切换同优先级可时间片轮转；阻塞/延时让出 CPU，不强占死循环

对选型的含义：如果你最在意可控的抢占路径和微秒级切换体感，FreeRTOS 这套模型足够直接，也更好在现有 MCU 工程里落地。

2.2 任务通信

队列好用，但不是唯一选择。写 FreeRTOS 任务通信，不用队列 Queue，你还有更好的选择？

FreeRTOS 针对多种不同的应用场景提供多种同步对象可以使用。

说明：

传数据优先看队列 / Stream Buffer只做事件通知可用二值信号量、任务通知共享资源保护用互斥锁；多事件组合看事件组没有“唯一正确对象”，按场景选型更重要

对选型的含义：FreeRTOS 把同步能力给齐了，但怎么组合、怎么约束团队用法，要靠项目工程约束。

2.3 FreeRTOSConfig.h

FreeRTOS 把大量行为交给 FreeRTOSConfig.h 裁剪：选择权在工程师，工程纪律也要团队自己补上。

说明：

时钟节拍、优先级数量、堆大小等多靠宏裁剪钩子函数、运行时统计、栈溢出检查可按项目打开配置灵活，也意味着各项目很容易长出“私有方言”

对选型的含义：小团队、边界清楚时这是优势；产品线一多，缺少统一配置规范就会变成隐性成本。

2.4 内存管理

理解 FreeRTOS 工程化，绕不开 heap 选型；高可靠项目更常见的是启动期一次分配、运行期不再动态申请。

关于 FreeRTOS heap 五种实现之前也有简单分享过：FreeRTOS 的 5 种堆方案，如何理解？

简单总结如下：

说明：

heap_1：只分配不释放，最简单也最确定heap_2 / heap_4：支持释放，碎片与合并策略不同heap_3：包一层标准库 malloc/freeheap_5：支持多块不连续内存区高可靠场景更常见：启动期分配完，运行期少动堆

对选型的含义：资源紧、要强确定性时，FreeRTOS 这套自己选堆策略的自由度很有价值。

2.5 FreeRTOS 的边界

FreeRTOS 的强项是把 kernel 做小、做稳、做容易移植；驱动、协议栈和平台层怎么长，通常由项目自己决定。

说明：

内核很克制：调度 + 同步对象做小、做稳，移植路径短平台要自己拼：SDK/HAL/BSP、TCP/IP、BLE、文件系统、OTA、日志等适合边界清楚、资源紧张、团队经验成熟的项目跨芯片 / 跨板型 / 跨协议长期演进时，若没有自建平台层，维护成本会持续上升

对选型的含义：已有稳定 HAL/中间件资产、交付周期紧时，FreeRTOS 迁移成本通常更低；反过来，若你准备长期跨硬件演进却不打算自建平台，后面会一直在补课。

往期相关文章：

FreeRTOS 任务栈：翻车原因、定位方法与防范技巧FreeRTOS 工程化要点：任务划分、优先级设计与 CPU 占用率监控FreeRTOS 必知！经典问题汇总！

3. Zephyr 整体架构

Zephyr 不只是一个 RTOS kernel，它更像一个面向嵌入式产品的平台工程体系。

https://docs.zephyrproject.org/latest/introduction/index.html#

它不是把一个 kernel 放进我们的工程，而是要求我们进入它的工程体系——这也是很多人觉得它「重」的原因。

说明：

从上到下：应用层 → 子系统 → 内核 → 驱动模型 → 构建与配置 → 板级描述子系统覆盖 networking、Bluetooth、USB、文件系统、logging、电源、安全等构建与配置靠 Devicetree / Kconfig / CMake / west 串起来它不只关心任务怎么调度，还关心硬件描述、驱动声明、功能裁剪和依赖构建

对选型的含义：你买到的是一套平台施工规范；小项目会觉得重，产品线才更容易赚回成本。

3.1 Devicetree

Zephyr 的 Devicetree 把硬件信息从业务代码里拿出来。

硬件信息写进 dts / overlay，业务只拿设备名；抽象发生在构建期，固件仍是静态编译结果。

说明：

传统写法：GPIO 口、引脚号散落在业务代码里，换板容易牵一发而动全身Zephyr：外设、总线、地址、引脚、中断写在 dts / overlay业务侧通常只拿设备名（如 led0），不绑死具体引脚宏处理发生在构建期，不是运行时再解析一套动态设备树

对选型的含义：如果未来大概率多板复用、换芯片不换业务骨架，Devicetree 这笔前期成本更值得付。

3.2 Kconfig

Zephyr 的 Kconfig 是软件能力的开关系统。

Devicetree 描述「板子上有什么」，Kconfig 决定「这次固件开什么」；价值在依赖关系，学习曲线也多半在这里。

说明：

Devicetree 管硬件有什么，Kconfig 管软件开什么依赖关系由配置系统约束，少靠口头约定和私有宏森林学习曲线主要在：会不会读依赖、会不会定位“为什么这个符号开不起来”

对选型的含义：团队愿意建立统一裁剪习惯时，Kconfig 是资产；若只有 1–2 人且交付很紧，学习曲线往往比协议栈红利更先到来。

3.3 Driver Model

Zephyr 的 Driver Model 很适合跨板迁移。

驱动不只是 HAL 函数，而是配置、binding、统一 API 和初始化优先级一套模型；小项目觉得重，产品线才慢慢赚回成本。

说明：

驱动绑定配置、设备名和统一 API，而不是各写一套裸 HAL 调用初始化顺序有优先级模型，子系统可按依赖起来跨板迁移时，业务更像“换 binding / overlay”，而不是重写外设访问代码

对选型的含义：单板单产品很少立刻感到爽；多 SKU、多硬件平台时，这套模型才开始回本。

3.4 Kernel

Zephyr 内核能力齐全，但更强调和日志、电源、userspace、驱动模型等平台能力协同——别把它当「另一个 FreeRTOS」硬套。

说明：

线程、调度、同步、内存、定时器等内核能力齐全更强调与 logging、电源管理、userspace、驱动模型协同若只把它当“换皮 FreeRTOS”用，往往既吃到重量，又吃不到平台红利

对选型的含义：选 Zephyr，本质上是选平台协同方式，不是只选另一个调度器 API。

3.5 West、CMake 与模块化工程

west + CMake + Kconfig/Devicetree 把「固件怎么拼出来」标准化了；从 Keil/CubeIDE 过来需要时间消化 workspace 与模块概念。

说明：

west 管理多仓 / 模块工作区，CMake 负责构建拼装模块、board、应用的边界比传统单工程 IDE 更清晰，也更陌生从 Keil / CubeIDE 过来，第一道坎通常不是语法，而是工程世界观

对选型的含义：团队若已有稳定 IDE 交付链路，切换成本要算进排期；若本来就要做多仓协作和长期平台维护，这套工具链更对口。

往期相关文章：

Zephyr SMF实战：几百行代码实现轻量状态机！Zephyr 会成为物联网时代RTOS的佼佼者？

4. 新项目怎么选

FreeRTOS vs Zephyr 核心对比

FreeRTOS 和 Zephyr 的差异，不是简单的新旧之争，也不是谁替代谁的问题。

4.1 核心维度对比

4.2 适合选 FreeRTOS 的项目

低成本 MCU、RAM/Flash 很紧，固件必须尽量瘦功能边界清楚：强实时控制、传感采集、单机控制类产品团队已有 CubeIDE / Keil / 自研 HAL 资产，要短周期交付不打算马上做多芯片复用，平台层可以先“够用就行”

团队只有 1–2 人、交付周期很紧时，Zephyr 的学习曲线往往比协议栈红利先到；这时 FreeRTOS 通常更稳。

4.3 适合选 Zephyr 的项目

多协议连接设备：BLE、Matter、Thread、LoRaWAN、TCP/IP 等要长期并行多硬件平台 / 多 SKU，希望业务少绑死某一家 HAL产品生命周期长，后续还要持续加安全能力、电源策略、子系统复用团队愿意先付 west / Devicetree / Kconfig 的学习成本，换后面的标准化收益

总结：选 FreeRTOS，是选可控的内核自由；选 Zephyr，是选可演进的平台标准。

欢迎大家在评论区聊聊，交流一下你的看法～