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。
參考連結：