嵌入式 on KnightLi的博客

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

參考連結：

2026 年嵌入式開發環境怎麼選：Keil、STM32CubeIDE、VS Code 與 AI 協作

Wed, 22 Apr 2026 23:05:00 +0800

只要你還在做單晶片或嵌入式開發，很快就會遇到一個很現實的問題：到了 2026 年，在 AI 寫程式已經越來越普遍的情況下，開發環境到底該怎麼選？

這個問題表面上像是在比較幾個 IDE，實際上討論的卻是另一件事：你到底是要一個「能把工程跑起來的工具」，還是一套「兼顧生態、編碼體驗與 AI 協作能力」的工作流。

如果從這個角度去看，答案往往就不是簡單地在 Keil、STM32CubeIDE、VS Code、CLion 裡選一個，而是重新組合它們各自最擅長的部分。

先看幾個主流選項，各自解決什麼問題

嵌入式領域這些年常見的環境，基本還是那幾類：

Keil
STM32CubeIDE
VS Code
CLion

如果再往前追，當然還會有人提 IAR。只是從今天的討論出發，更值得看的已經不是「誰資歷最老」，而是誰更適合當前這套開發現實。

Keil：生態強、上手穩，但編輯體驗已經明顯落後

Keil 到今天仍然很難繞開，原因不複雜：它用得實在太廣了。

無論是公司裡留下來的老工程，還是網上大量教學、資料、示例工程，很多都還是圍繞 Keil 組織的。它在編譯、下載、調試這一整套流程上依然成熟，尤其是你真的要把板子跑起來時，它的路徑非常短。

它的問題也同樣明顯：

介面老
編輯體驗一般
不擅長承擔 AI 輔助寫程式的主場

所以 Keil 更像是一個「工程入口和調試底座」，而不是一個面向 2026 年編碼體驗的理想編輯環境。

STM32CubeIDE：對 STM32 友好，但更多是學習和快速起步工具

如果你主要在 STM32 生態裡活動，STM32CubeIDE 很容易成為第一個接觸到的環境。

它的優點很明確：

上手友好
外設配置和工程生成方便
調試鏈路相對完整

對學生、新手和剛起步的專案來說，這套體驗確實足夠直接。

但一旦進入更長期、更多協作、更多客製化的工程環境，它的局限也會慢慢暴露出來。尤其是在商業專案或更複雜的團隊工作流裡，它未必是那個最舒服的主環境。

所以它更適合「快速啟動」和「STM32 生態內的一體化體驗」，不一定適合作為長期主力編輯器。

VS Code：嚴格來說不是 IDE，但在 AI 時代優勢越來越明顯

VS Code 嚴格來說並不是傳統意義上的 IDE，更準確地說，它是一個可擴充的程式碼編輯器。

這也意味著它天然有兩面性。

它的弱點是：

需要外掛和配置
對新手不夠友好
不能開箱即用地取代嵌入式 IDE 全流程

但它真正強的地方，恰恰也在這裡：

可擴充性強
編碼體驗明顯更現代
語法高亮、跳轉、搜尋、重構體驗更好
對 AI 工具和 Agent 工作流支援更積極

在今天這個階段，很多人真正需要的已經不只是「能寫程式」，而是「寫程式時能不能順手把 AI 協作接進來」。從這個角度看，VS Code 的優勢幾乎是肉眼可見的。

CLion：體驗不錯，但在嵌入式場景裡不夠主流

CLion 經常會被提到，因為它的 C/C++ 編碼體驗一直不差。

但對很多嵌入式開發者來說，它的問題不一定出在「好不好用」，而是「值不值得切過去」：

用的人相對少
與現有嵌入式工程生態連接不如 Keil 直接
在 AI 協作這件事上，也未必比 VS Code 更有現實優勢

所以它更像是一個「理論上也能做得不錯」的選項，但在今天的嵌入式主流工作流裡，並不是最自然的那個核心。

更現實的答案：Keil 負責編譯調試，VS Code 負責寫程式

如果把上面這些工具拆開來看，很容易得到一個更務實的結論：

用 Keil 保留現有工程生態、編譯、下載和調試能力
用 VS Code 承擔日常編碼、搜尋、跳轉和 AI 協作

這套組合的價值在於，它不是試圖用一個工具包打天下，而是讓每個工具回到自己最擅長的位置。

對很多嵌入式工程來說，Keil 的生態根本繞不開。既然如此，與其強行把所有工作都塞回 Keil，不如承認它更適合作為後端編譯調試入口；而真正的編輯體驗，則交給 VS Code。

為什麼這套組合在 AI 時代更有優勢

到了今天，開發環境的分界線已經不只是「編輯器順不順手」，而是「它能不能自然接入 AI」。

VS Code 在這件事上有幾個很現實的優勢：

AI 外掛和 Agent 支援更活躍
程式碼瀏覽體驗更適合讓 AI 讀工程、改工程
更容易和現代外掛生態結合

這意味著你可以把嵌入式開發裡最痛苦的一部分工作，開始交給 AI 幫你分擔：

在現有工程裡找函式和呼叫鏈
快速生成一段初始化程式碼
幫你補一個串口列印
解釋舊工程結構
在既有檔案裡做小範圍修改

這些事情過去不是不能做，而是做起來不順。VS Code 的意義不只是「更好看」，而是它更容易成為 AI 協作的工作台。

關鍵補丁：用外掛把 VS Code 和 Keil 工程接起來

這套工作流能不能成立，核心不在口號，而在你能不能把 VS Code 和 Keil 工程接起來。

比較實用的一類外掛思路，是讓 VS Code 直接讀取 Keil 工程結構，並在編輯器內部呼叫 Keil 後台程式完成：

打開工程
編譯
下載

這樣一來，你日常寫程式不用頻繁在兩個介面之間來回切，只有到了更重的調試環節，再回到 Keil 裡做單步、斷點和寄存器觀察。

這類外掛真正有價值的地方，不只是「少切幾個視窗」，而是它讓工作流連續起來了。

不要忽視 C/C++ 基礎外掛配置

如果你打算把 VS Code 當作嵌入式主編輯器，一個非常基礎但常被忽略的點是：一定要把 C/C++ 基礎外掛和工程索引配置好。

否則你會遇到一系列很影響體驗的問題：

跳轉不到定義
紅線誤報
補全不準
標頭檔關係混亂

很多人會誤以為是 VS Code 不適合嵌入式，實際上往往只是工程索引和外掛配置沒接好。

一旦這部分配置完整，VS Code 才能真正發揮出它在閱讀大型工程、搜尋符號、配合 AI 輔助修改程式碼上的優勢。

這套工作流最適合誰

我覺得下面這幾類人，會特別適合這種組合式環境。

1. 已經有大量 Keil 工程的人

如果你公司專案、課程資料或歷史程式碼都圍繞 Keil 展開，那就沒必要為了「現代化」硬切掉原有生態。保留 Keil，再補一個 VS Code 前端，是遷移成本最低的做法。

2. 想用 AI 輔助寫嵌入式程式的人

如果你已經習慣讓 AI 幫你解釋函式、補樣板程式碼、改局部邏輯，那麼 VS Code 會比傳統嵌入式 IDE 更自然地承接這件事。

3. 想同時兼顧學習資料和真實專案的人

很多學習資料仍然建立在 Keil 上，但你自己的工作流未必要停留在那個年代。把 Keil 作為工程相容層，把 VS Code 作為生產力層，會更平衡。

結語

到了 2026 年，嵌入式開發環境的關鍵問題，已經不再只是「哪個 IDE 功能更多」，而是「哪種組合最符合今天的工作方式」。

如果你只想快速起步，STM32CubeIDE 依然有它的位置；如果你要穩定接住大量既有工程，Keil 依然繞不開；但如果你還想把現代編輯體驗和 AI 協作一起接進來，那麼更現實的答案，往往是：

Keil 負責編譯和調試，VS Code 負責寫程式。

這不一定是唯一答案，但很可能是當下最不彆扭的一種答案。

CH347 開發常用資源整理：驅動、工具與 SPI Flash 刷寫

Fri, 03 Apr 2026 10:00:00 +0800

這篇文章整理我在使用 CH347 時最常用的一組資源，目標是開箱就能開始調試與刷寫。

如果你剛接觸 CH347，建議依照下面順序準備環境：

先看官方產品頁確認資料入口
依用途安裝對應驅動
準備 SPI Flash 刷寫工具並做連通性驗證

官方入口

CH347 產品頁：https://www.wch.cn/products/CH347.html

建議優先從官方頁面進入下載區，避免拿到來源不明或版本過舊的驅動包。

常用驅動

1) `CH341PAR.EXE`

用途：

USB 轉 JTAG / SPI / I2C / 並口 / GPIO 等介面驅動

適用情境：

需要用 CH347 做多協議通訊或底層介面調試時

2) `CH343SER.EXE`

用途：

USB 轉高速序列埠 Windows 廠商驅動