星標公眾號，讓嵌入式知識 “投喂” 不停歇！
大家好，我是雜燴君。
最近有粉絲朋友問：新項目到底上 FreeRTOS，還是直接上 Zephyr？
我的理解是，這不是新舊之爭，也不是誰替代誰，而是兩種工程路徑：
先給結論：
邊界清楚、資源緊、團隊已有成熟 MCU/Cube 經驗，優先 FreeRTOS；多板復用、連接協議多、產品線要長期演進，且愿意為工程體系付學習成本，更適合 Zephyr。
下面先對齊兩邊都繞不開的 RTOS 共性，再分別看 FreeRTOS 和 Zephyr 整體架構。
不管 FreeRTOS 還是 Zephyr，RTOS 最核心的任務都不是讓程序變復雜，而是解決前后臺系統在復雜項目里調度與解耦越來越難的問題。
前后臺大家都很熟：前臺是中斷，后臺是一個大 while(1)。項目一復雜，順序輪詢就開始互相拖累。
RTOS 做的第一件事，就是把它拆成可搶占的多任務，由調度器決定誰跑、誰等：
說明：
每個任務看起來都像一個獨立的 while(1)，但 CPU 只有一個或少數幾個核心。下面幾個基礎概念，兩邊 RTOS 都繞不開：
說明：
從這個角度看，FreeRTOS 和 Zephyr 的共同點是：它們都在解決多任務調度、實時響應、任務通信和資源管理問題。選型差異，主要不在“會不會調度”，而在平臺層你要不要自己拼。
FreeRTOS 官網：https://www.freertos.org/
FreeRTOS 的主角是 kernel，不是大而全操作系統。
使用 FreeRTOS 開發的項目，工程結構大概是這樣：
說明：
也就是說，FreeRTOS 很少規定我們必須怎么組織驅動、怎么描述板級資源、怎么管理協議棧依賴。它把最核心的調度和同步機制做好，然后把大量工程組織自由度留給我們。
這就是它輕的原因，也是它長期流行的原因。
調度器是 FreeRTOS 的心臟。
FreeRTOS 調度器圍繞任務優先級工作：就緒、延時、阻塞與上下文切換，把實時性落實在短路徑上。
FreeRTOS 調度器之前我們也有分享過：FreeRTOS調度器：搶占與輪轉機制
簡單總結如下：
說明：
對選型的含義：如果你最在意可控的搶占路徑和微秒級切換體感，FreeRTOS 這套模型足夠直接，也更好在現有 MCU 工程里落地。
隊列好用，但不是唯一選擇。寫 FreeRTOS 任務通信，不用隊列 Queue，你還有更好的選擇？
FreeRTOS 針對多種不同的應用場景提供多種同步對象可以使用。
說明：
對選型的含義：FreeRTOS 把同步能力給齊了，但怎么組合、怎么約束團隊用法，要靠項目工程約束。
FreeRTOSConfig.hFreeRTOS 把大量行為交給 FreeRTOSConfig.h 裁剪：選擇權在工程師，工程紀律也要團隊自己補上。
說明：
對選型的含義：小團隊、邊界清楚時這是優勢；產品線一多，缺少統一配置規范就會變成隱性成本。
理解 FreeRTOS 工程化，繞不開 heap 選型；高可靠項目更常見的是啟動期一次分配、運行期不再動態申請。
關于 FreeRTOS heap 五種實現之前也有簡單分享過：FreeRTOS 的 5 種堆方案，如何理解？
簡單總結如下：
說明：
對選型的含義：資源緊、要強確定性時，FreeRTOS 這套自己選堆策略的自由度很有價值。
FreeRTOS 的強項是把 kernel 做小、做穩、做容易移植；驅動、協議棧和平臺層怎么長，通常由項目自己決定。
說明：
對選型的含義：已有穩定 HAL/中間件資產、交付周期緊時，FreeRTOS 遷移成本通常更低；反過來，若你準備長期跨硬件演進卻不打算自建平臺，后面會一直在補課。
往期相關文章：
Zephyr 不只是一個 RTOS kernel，它更像一個面向嵌入式產品的平臺工程體系。
https://docs.zephyrproject.org/latest/introduction/index.html#
它不是把一個 kernel 放進我們的工程，而是要求我們進入它的工程體系——這也是很多人覺得它「重」的原因。
說明：
對選型的含義：你買到的是一套平臺施工規范；小項目會覺得重，產品線才更容易賺回成本。
Zephyr 的 Devicetree 把硬件信息從業務代碼里拿出來。
硬件信息寫進 dts / overlay，業務只拿設備名；抽象發生在構建期，固件仍是靜態編譯結果。
說明：
對選型的含義：如果未來大概率多板復用、換芯片不換業務骨架，Devicetree 這筆前期成本更值得付。
Zephyr 的 Kconfig 是軟件能力的開關系統。
Devicetree 描述「板子上有什么」，Kconfig 決定「這次固件開什么」；價值在依賴關系，學習曲線也多半在這里。
說明：
對選型的含義：團隊愿意建立統一裁剪習慣時，Kconfig 是資產；若只有 1–2 人且交付很緊，學習曲線往往比協議棧紅利更先到來。
Zephyr 的 Driver Model 很適合跨板遷移。
驅動不只是 HAL 函數，而是配置、binding、統一 API 和初始化優先級一套模型；小項目覺得重，產品線才慢慢賺回成本。
說明：
對選型的含義：單板單產品很少立刻感到爽；多 SKU、多硬件平臺時，這套模型才開始回本。
Zephyr 內核能力齊全，但更強調和日志、電源、userspace、驅動模型等平臺能力協同——別把它當「另一個 FreeRTOS」硬套。
說明：
對選型的含義：選 Zephyr，本質上是選平臺協同方式，不是只選另一個調度器 API。
west + CMake + Kconfig/Devicetree 把「固件怎么拼出來」標準化了；從 Keil/CubeIDE 過來需要時間消化 workspace 與模塊概念。
說明：
對選型的含義：團隊若已有穩定 IDE 交付鏈路，切換成本要算進排期；若本來就要做多倉協作和長期平臺維護，這套工具鏈更對口。
往期相關文章：
FreeRTOS 和 Zephyr 的差異，不是簡單的新舊之爭，也不是誰替代誰的問題。
團隊只有 1–2 人、交付周期很緊時，Zephyr 的學習曲線往往比協議棧紅利先到；這時 FreeRTOS 通常更穩。
總結：選 FreeRTOS，是選可控的內核自由；選 Zephyr，是選可演進的平臺標準。
歡迎大家在評論區聊聊，交流一下你的看法～
