FreeRTOS、RT-Thread、Zephyr 經常被放在一起比較，但這三個專案其實不在同一個層級。
如果只問“哪個 RTOS 更好”，答案很容易跑偏。更準確的問題應該是：你的專案到底需要一個輕量排程核心、一個帶國產 MCU 生態的 RTOS，還是一個面向跨平臺工程化的完整嵌入式作業系統。
從這個角度看，三者的定位可以先粗略分成這樣：
- FreeRTOS：行業標配級排程核心，外加 AWS 維護的一組 IoT 庫。
- RT-Thread：核心加較完整元件生態，對國內長尾 MCU 和中文社群更友好。
- Zephyr：Linux Foundation 託管的完整 RTOS，強調統一子系統、裝置模型、Devicetree 和跨廠商應用複用。
先說結論
如果專案只是小 MCU、簡單任務排程、訊號量、佇列、定時器，FreeRTOS 仍然是最穩的選擇之一。
如果專案主要面向國內 MCU，尤其是 AT32、HC32、N32、APM32、HT32、合宙等長尾晶片，並且團隊希望中文資料、BSP 和社群反饋更順手，RT-Thread 很有優勢。
如果專案需要跨晶片、跨板卡、跨廠商複用應用層程式碼，並且願意接受 Kconfig、Devicetree、west、驅動模型帶來的學習成本，Zephyr 更像是面向未來工程化的路線。
所以這不是“誰淘汰誰”的問題，而是三種工程抽象層級不同。
FreeRTOS：最強的是輕量和確定性
FreeRTOS 的核心優勢，是足夠小、足夠熟、足夠普及。
它的主倉庫 FreeRTOS-Kernel 重點就是核心、移植層和核心 RTOS 機制。任務排程、訊號量、訊息佇列、事件組、軟體定時器、記憶體分配策略，這些是絕大多數專案真正使用的部分。
FreeRTOS 的好處很直接：
- MCU 覆蓋極廣。
- 學習資料和工程案例最多。
- 可以很容易塞進晶片廠商 SDK。
- 適合資源很緊、需求很明確的小系統。
- 出問題時定位路徑短，很多團隊已有經驗積累。
AWS 收購 FreeRTOS 後，又圍繞它維護了 coreMQTT、coreHTTP、OTA、Device Shadow、Jobs、Defender 等 IoT 相關庫。FreeRTOS 202406 LTS 也把核心、TCP、MQTT、HTTP、OTA 等元件納入長期支援路線。
但 FreeRTOS 的邊界也很清楚：它本質上不是一個“完整 OS 平臺”。GPIO 怎麼抽象、UART 怎麼讀寫、I2C 怎麼掛裝置、不同廠商 HAL 怎麼統一，FreeRTOS 自己並不負責。
換句話說，FreeRTOS 給你的主要是核心。驅動層、裝置模型、板級抽象和應用框架，要麼依賴晶片廠商 SDK，要麼由團隊自己搭。
這不是缺陷，而是設計選擇。它讓 FreeRTOS 非常靈活，也讓它很容易和 ST、NXP、TI、瑞薩、樂鑫等廠商 SDK 組合。但代價是：換晶片、換板子、換 HAL 時，應用層往往也會被牽連。
RT-Thread：優勢在國內 MCU 和元件生態
RT-Thread 比 FreeRTOS 更接近一個完整 RTOS。
它不只是排程器，還提供檔案系統、網路協議棧、裝置框架、USB、感測器框架、元件包和工具鏈。對很多國內團隊來說，RT-Thread 的中文文件、ENV 工具、社群氛圍和國產 MCU BSP 是很實際的優勢。
尤其在國內長尾 MCU 上，RT-Thread 的支援面很有價值。很多專案並不使用頭部國際廠商晶片，而是會選 AT32、HC32、N32、APM32、HT32、合宙、先楫等國產 MCU。對這類專案，RT-Thread 往往能更快拿到可跑的 BSP 和中文資料。
RT-Thread 適合這些場景：
- 團隊主要使用國產 MCU。
- 需要中文社群和本土資料。
- 需要比 FreeRTOS 更完整的元件生態。
- 專案希望快速接入檔案系統、網路、shell、裝置框架等能力。
- 團隊不想從零搭一套板級和驅動抽象。
但 RT-Thread 也有自己的限制。
第一，它的很多 BSP 仍然是圍繞具體板卡和廠商庫組織。雖然有裝置框架，但從跨廠商統一硬體描述和應用層無感遷移的角度看，還沒有達到 Zephyr 那種系統性。
第二，RT-Thread 對國內長尾 MCU 很友好，但在一些頭部晶片和國際廠商主線維護上，Zephyr 的勢頭已經很強。比如樂鑫、Nordic、NXP、瑞薩等廠商，在 Zephyr 生態中的官方投入越來越明顯。
第三，RT-Thread 的裝置樹路線還沒有真正成為 MCU 側的主流工作方式。它有 ofw 相關框架，但在 Cortex-M 這類 MCU 專案裡，還不能像 Zephyr 那樣形成貫穿構建系統、驅動匹配、應用層配置的統一機制。
所以 RT-Thread 的定位更像：在 FreeRTOS 之上補齊了很多常用系統元件，並且在國內 MCU 生態裡非常實用。但它還不是 Zephyr 那種從構建、配置、驅動、裝置模型到應用層都統一規劃的工程平臺。
Zephyr：不是“另一個 RTOS”，而是一套系統工程
Zephyr 容易被誤解為“比 FreeRTOS 更復雜的 RTOS”。這個說法只說對了一半。
它確實更復雜，但複雜的原因不是單純堆功能，而是它試圖把 MCU 專案里長期散落在廠商 SDK、BSP、HAL、手寫驅動、配置指令碼里的東西，統一進一個作業系統工程。
Zephyr 的關鍵不只是排程器，而是這些東西：
- Kconfig：管理功能開關和編譯配置。
- Devicetree：描述板級硬體和外設連線。
- drivers：統一 GPIO、UART、SPI、I2C、ADC、DMA、clock、reset、pinctrl 等外設介面。
- subsys：提供網路、藍芽、USB、檔案系統、輸入、電源管理、日誌、設定儲存等子系統。
- west 和 CMake：管理工程、模組、構建、下載和除錯。
- 板卡 / SoC / shield 抽象：把硬體差異收斂到配置層。
這使得 Zephyr 更像一個“嵌入式 Linux 的 MCU 縮小版”：它繼承了 Linux 世界的很多工程思想，但把執行時 probe 那套不適合小 MCU 的機制，改造成了編譯期展開。
Zephyr 的 Devicetree 為什麼關鍵
Devicetree 是理解 Zephyr 的關鍵。
在 Linux 裡，DTS 通常會編譯成 DTB，由 bootloader 傳給核心，核心啟動後再解析裝置樹、匹配驅動、執行 probe。這個執行時模型對 MPU 和大記憶體系統很合理，但對一顆幾十 KB 到幾百 KB RAM 的 MCU 來說太重。
Zephyr 的做法不一樣。它在構建階段處理 DTS / overlay，把硬體描述生成 devicetree_generated.h 這類標頭檔案，再透過 DT_ 宏給驅動和應用使用。換句話說，硬體描述和驅動選擇在編譯期就基本確定，執行時不需要再做一套沉重的裝置發現。
這個設計帶來幾個好處：
- 硬體描述和應用程式碼分離。
- 換板子主要改 DTS / overlay。
- 驅動透過統一 API 暴露給應用。
- 未啟用的驅動和子系統可以被裁掉。
- 應用層不必直接關心具體暫存器、引腳和廠商 HAL。
比如一個 LED 或按鍵，在傳統 FreeRTOS + 廠商 HAL 工程裡，通常會散落在 CubeMX 配置、GPIO 初始化、回撥、中斷、去抖、狀態機和應用程式碼裡。到了 Zephyr，很多資訊可以放進 DTS，應用層只透過 LED、GPIO 或 input 子系統介面處理事件。
這就是 Zephyr 的工程化價值：不是讓簡單 demo 看起來更短，而是讓複雜專案的硬體差異儘量不汙染業務程式碼。
應用層程式碼為什麼會變乾淨
傳統 MCU 工程裡，應用程式碼經常混著這些內容：
- 硬體初始化。
- GPIO 引腳號。
- 中斷配置。
- 去抖邏輯。
- 定時器和狀態機。
- 串列埠重定向。
- 事件佇列。
- 業務處理。
專案一開始不大時，這樣寫很快。但隨著外設變多、板卡變多、產品線變多，應用層會越來越像 BSP 的延伸。
Zephyr 的目標是把這些內容拆開：
- 硬體連線放到 DTS / overlay。
- 功能開關放到 Kconfig / prj.conf。
- 驅動放到 Zephyr 主線或模組。
- 應用只處理業務事件。
因此，同樣是 LED 閃爍、按鍵短按、長按、雙擊、三擊這類功能，在 Zephyr 裡更容易變成“少量業務程式碼 + 配置檔案”。換板卡時，理想狀態是改 DTS，不改 main.c。
這對單板 demo 未必顯得划算，但對多板卡、多晶片、多代產品的團隊，價值會越來越明顯。
資源佔用不能只看第一眼
很多人第一反應是：Zephyr 這麼大，資源佔用肯定高。
這個判斷要拆開看。
Zephyr 的 Flash 通常會因為統一驅動、子系統、裝置模型而比裸 FreeRTOS 工程多一些。這部分不是純“核心開銷”，而是你買下了一套可複用基礎設施。
比如 input 子系統、LED 驅動、GPIO 驅動、定時器、日誌、裝置物件等，都會佔空間。但後續再加旋鈕、編碼器、更多按鍵、更多輸入裝置時，很多基礎設施可以複用，不是每個功能都重新手寫一套。
RAM 也類似。FreeRTOS 工程裡常見的 heap 預留、任務棧預留、佇列緩衝可能會讓報表看起來更大；Zephyr 更強調靜態物件和連結期裁剪。具體誰更省，要看配置、功能、編譯選項和實際場景，不能只拿空工程對比。
更實用的判斷方式是：
- 如果功能很少、板卡固定、資源極緊，FreeRTOS 可能更省。
- 如果外設多、板卡多、驅動複用多，Zephyr 的“基礎設施成本”會被攤薄。
- 如果團隊沒有時間學習 Zephyr，複雜性本身就是成本。
三者怎麼選
可以按專案形態來選。
選擇 FreeRTOS
適合：
- 專案資源很緊。
- 只需要排程、佇列、訊號量、定時器。
- 硬體平臺固定。
- 已經有成熟廠商 SDK。
- 團隊對 FreeRTOS 很熟。
- 不需要跨廠商統一裝置模型。
典型判斷：你需要的是一個可靠核心，而不是一整套 OS 工程框架。
選擇 RT-Thread
適合：
- 使用國產 MCU 較多。
- 需要中文社群和中文資料。
- 希望快速拿到 BSP、元件包和常用系統能力。
- 專案規模比純 FreeRTOS 大，但還不想全面進入 Zephyr 學習曲線。
- 團隊希望在本土生態裡解決問題。
典型判斷：你需要的是“FreeRTOS 之上更多元件 + 國產 MCU 友好生態”。
選擇 Zephyr
適合：
- 專案要跨多塊板、多顆晶片、多家廠商。
- 希望應用層儘量不綁死具體硬體。
- 重視長期維護和主線升級。
- 需要藍芽、網路、USB、檔案系統、輸入、電源管理等統一子系統。
- 團隊願意學習 Kconfig、Devicetree、west 和 Zephyr 驅動模型。
- 未來希望和 Linux 工程思想接軌。
典型判斷：你需要的是一套完整的嵌入式系統工程平臺，而不僅是 RTOS 核心。
什麼時候不該用 Zephyr
Zephyr 不是銀彈。
這些情況下不建議上來就選 Zephyr：
- 專案只有一個固定板卡，功能很簡單。
- 團隊沒有時間學習 Kconfig 和 Devicetree。
- 晶片或板卡在 Zephyr 主線支援很弱。
- 專案強依賴某個廠商 SDK 的私有閉源能力。
- 產品已經穩定量產，遷移收益不明顯。
- 團隊除錯和構建環境還沒有準備好。
Zephyr 的學習成本是真實存在的。它的錯誤資訊、構建系統、Devicetree 繫結、Kconfig 依賴、module 管理，對傳統裸機 / FreeRTOS 開發者來說都需要適應。
所以更合理的路線是：先選一塊 Zephyr 主線支援好的開發板，用一個小功能跑通 LED、UART、GPIO、input、I2C / SPI，再決定是否遷移真實專案。
AI 時代為什麼更要讀好程式碼
現在很多人會說：有 AI 了，底層框架沒必要學那麼深，直接讓模型寫程式碼就行。
這個想法很危險。
AI 能把候選程式碼擺在你面前，但把程式碼合進去、燒進韌體、交給客戶裝置執行的人，仍然是工程師。AI 不會為裝置召回負責，人會。
嵌入式專案裡，真正稀缺的不是“多寫幾百行程式碼”的能力，而是判斷力：
- 這段程式碼為什麼這麼寫？
- 這層抽象值不值得？
- 這個驅動介面能不能長期維護？
- 這個配置變更會不會影響別的板卡？
- 這段 AI 生成程式碼能不能進入量產韌體？
Zephyr 的價值之一，就是提供了一套工業級嵌入式系統架構樣本。即使最後專案不選 Zephyr，讀懂它的子系統、裝置模型、Devicetree、Kconfig 和驅動組織方式，也會提升你判斷嵌入式架構好壞的能力。
總結
FreeRTOS、RT-Thread、Zephyr 不是同類產品的簡單三選一。
FreeRTOS 是輕量、成熟、普及的 RTOS 核心，適合固定硬體和清晰任務排程場景。RT-Thread 是更完整的 RTOS 生態，尤其適合國內 MCU、中文社群和快速元件整合。Zephyr 則是更系統化的嵌入式作業系統工程，適合跨廠商、跨板卡、長期維護和應用層複用。
如果只做一個小裝置，FreeRTOS 可能就是最省事的答案。如果做國內 MCU 產品線，RT-Thread 的生態會很實際。如果你面對的是多平臺、多板卡、多外設和長期演進，Zephyr 值得認真投入。
真正的差距，不是 API 多幾個少幾個，而是工程抽象層級：FreeRTOS 解決排程，RT-Thread 補齊元件，Zephyr 試圖重構 MCU 軟體工程的組織方式。
參考連結：