FreeRTOS、RT-Thread、Zephyr 怎麼選？三大 RTOS 架構差異與適用場景

Sun, 17 May 2026 12:32:06 +0800

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 軟體工程的組織方式。

參考連結：

技術文件 on KnightLi的博客