来源 | 嵌入式大杂烩
当下，FreeRTOS 和 Zephyr 是最热门的两款RTOS ，很多网友会问：新项目到底上 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 调度器之前我们也有分享过：
简单总结如下：
说明：
任务由栈、TCB、优先级和状态组成 调度路径短：就绪队列挑最高优先级，必要时做上下文切换 同优先级可时间片轮转；阻塞/延时让出 CPU，不强占死循环
对选型的含义：如果你最在意可控的抢占路径和微秒级切换体感，FreeRTOS 这套模型足够直接，也更好在现有 MCU 工程里落地。
2.2 任务通信
队列好用，但不是唯一选择。
FreeRTOS 针对多种不同的应用场景提供多种同步对象可以使用。
说明：
传数据优先看队列 / Stream Buffer 只做事件通知可用二值信号量、任务通知 共享资源保护用互斥锁；多事件组合看事件组 没有“唯一正确对象”，按场景选型更重要
对选型的含义：FreeRTOS 把同步能力给齐了，但怎么组合、怎么约束团队用法，要靠项目工程约束。
2.3 FreeRTOSConfig.h
FreeRTOS 把大量行为交给 FreeRTOSConfig.h 裁剪：选择权在工程师，工程纪律也要团队自己补上。
说明：
时钟节拍、优先级数量、堆大小等多靠宏裁剪 钩子函数、运行时统计、栈溢出检查可按项目打开 配置灵活，也意味着各项目很容易长出“私有方言”
对选型的含义：小团队、边界清楚时这是优势；产品线一多，缺少统一配置规范就会变成隐性成本。
2.4 内存管理
理解 FreeRTOS 工程化，绕不开 heap 选型；高可靠项目更常见的是启动期一次分配、运行期不再动态申请。
关于 FreeRTOS heap 五种实现之前也有简单分享过：
简单总结如下：
说明：
heap_1：只分配不释放，最简单也最确定 heap_2 / heap_4：支持释放，碎片与合并策略不同 heap_3：包一层标准库 malloc/free heap_5：支持多块不连续内存区 高可靠场景更常见：启动期分配完，运行期少动堆
对选型的含义：资源紧、要强确定性时，FreeRTOS 这套自己选堆策略的自由度很有价值。
2.5 FreeRTOS 的边界
FreeRTOS 的强项是把 kernel 做小、做稳、做容易移植；驱动、协议栈和平台层怎么长，通常由项目自己决定。
说明：
内核很克制：调度 + 同步对象做小、做稳，移植路径短 平台要自己拼：SDK/HAL/BSP、TCP/IP、BLE、文件系统、OTA、日志等 适合边界清楚、资源紧张、团队经验成熟的项目 跨芯片 / 跨板型 / 跨协议长期演进时，若没有自建平台层，维护成本会持续上升
对选型的含义：已有稳定 HAL/中间件资产、交付周期紧时，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 交付链路，切换成本要算进排期；若本来就要做多仓协作和长期平台维护，这套工具链更对口。
往期相关文章：
4. 新项目怎么选
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，是选可演进的平台标准。
------------ END ------------
