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 和跨廠商應用複用。

先說結論

如果只需要任務、佇列、信號量、計時器和很小的資源佔用，FreeRTOS 仍然是最穩的選擇之一。

如果主要使用國產 MCU，需要現成 BSP、中文文件、ENV 工具和更多系統元件，RT-Thread 很實用。

如果要跨晶片、跨板卡、跨廠商複用應用層程式碼，並且團隊願意承擔 Kconfig、Devicetree、west 和驅動模型的學習成本，Zephyr 更像面向長期工程化的路線。

FreeRTOS：輕量、熟悉、確定

FreeRTOS 的優勢在於小、熟、普及。

FreeRTOS-Kernel 主要提供核心、移植層和 RTOS 基礎機制，例如任務調度、信號量、佇列、事件組、軟體計時器與記憶體分配。很多專案真正使用的也正是這些部分。

它適合資源很緊、硬體固定、需求明確的小系統。AWS 收購後，FreeRTOS 周邊也有 coreMQTT、coreHTTP、OTA、Device Shadow 等 IoT 函式庫，並有 LTS 長期支援線。

但 FreeRTOS 本質上不是完整 OS 平台。GPIO 怎麼抽象、UART 怎麼讀、I2C 怎麼掛設備、不同廠商 HAL 怎麼統一，FreeRTOS 自己不處理。這讓它很靈活，也讓換板、換晶片時容易牽動應用層。

RT-Thread：國產 MCU 與元件生態更友好

RT-Thread 比 FreeRTOS 更接近完整 RTOS。

它不只有調度器，也提供檔案系統、網路、設備框架、USB、感測器框架、套件與工具鏈。對很多中文團隊來說，文件、社群、ENV 和 BSP 覆蓋是很實際的優勢。

尤其是 AT32、HC32、N32、APM32、HT32、合宙、先楫等國產長尾 MCU，RT-Thread 往往能提供更快的起點。

它的限制是，很多 BSP 仍然偏具體板卡和廠商庫組織。從跨廠商硬體描述、應用層無感遷移的角度看，還沒有 Zephyr 那麼系統化。

Zephyr：不是另一個 RTOS，而是一套工程平台

Zephyr 的複雜度來自它想把 MCU 專案裡散落在廠商 SDK、BSP、HAL、手寫驅動和配置腳本中的內容，統一進一套 OS 工程。

它的關鍵包括：

Kconfig：管理功能開關。
Devicetree：描述板級硬體。
drivers：統一 GPIO、UART、SPI、I2C、ADC、DMA、clock、reset、pinctrl 等接口。
subsys：提供網路、藍牙、USB、檔案系統、input、電源管理、log 等子系統。
west / CMake：管理專案、模組、構建和燒錄。

因此 Zephyr 更像 MCU 尺寸的嵌入式 Linux 思路：保留系統工程能力，但把昂貴的 runtime probe 移到編譯期。

Devicetree 為什麼重要

Zephyr 在構建階段處理 DTS / overlay，生成 devicetree_generated.h 等檔案，驅動和應用再透過 DT_ 宏取得硬體資訊。這讓硬體描述和應用程式碼分離，換板主要改 DTS，而不是到處改 main.c。

LED、按鍵、I2C 感測器這類外設，在傳統 FreeRTOS + HAL 工程裡可能散落在初始化、回呼、中斷、去抖和應用邏輯中；在 Zephyr 中，很多資訊可以放進 DTS 和標準子系統。

應用層為什麼更乾淨

傳統 MCU 工程常把硬體初始化、引腳號、中斷、去抖、狀態機、事件佇列和業務邏輯混在一起。專案小時很快，板卡和產品線變多後就會痛苦。

Zephyr 希望把它們拆開：

硬體連線放 DTS / overlay。
功能開關放 Kconfig / prj.conf。
驅動放主線或 module。
應用只處理業務事件。

這對多板卡、多晶片、長期維護的產品尤其有價值。

資源佔用要看場景

Zephyr 的 Flash 可能比最小 FreeRTOS 工程多，因為它帶了統一驅動、子系統和設備物件。但這不是純浪費，而是一套可複用基礎設施。

如果功能少、板卡固定、資源極緊，FreeRTOS 可能更省。如果外設多、板卡多、長期演進，Zephyr 的基礎設施成本會被攤薄。

三者怎麼選

選 FreeRTOS：硬體固定、資源緊、只需要調度原語、團隊熟悉它。

選 RT-Thread：國產 MCU 多、需要中文社群、BSP 和常用元件，希望快速落地。

選 Zephyr：需要跨平台、長期維護、統一驅動、Devicetree、子系統和接近 Linux 的工程思路。

什麼時候不該用 Zephyr

如果專案只有單板、功能簡單、團隊沒有時間學 Kconfig / Devicetree，或晶片在 Zephyr 主線支持很弱，就不必急著遷移。已穩定量產的產品，也要謹慎評估遷移收益。

更穩的方式是先選主線支持好的開發板，跑通 LED、UART、GPIO、input、I2C / SPI，再決定是否導入真實專案。

AI 時代更要讀好程式碼

AI 可以生成候選程式碼，但把程式碼合進去、燒進設備、交付客戶的人仍然是工程師。真正稀缺的是判斷力：抽象是否值得、驅動接口是否能維護、配置變更是否影響其他板卡。

即使最後不選 Zephyr，讀懂它的子系統、Devicetree、Kconfig 和驅動組織方式，也能提升嵌入式架構判斷力。

總結

FreeRTOS 解決調度，RT-Thread 補齊元件並強化國產 MCU 生態，Zephyr 則試圖用統一子系統、Devicetree 和設備模型重組 MCU 軟體工程。

小型固定設備可以選 FreeRTOS；國產 MCU 產品線可以優先看 RT-Thread；多平台、多板卡、長期維護的產品，值得認真投入 Zephyr。

參考連結：

RTOS on KnightLi的博客