FreeRTOS、RT-Thread、Zephyr の選び方：3 大 RTOS のアーキテクチャ差と適用場面

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

FreeRTOS、RT-Thread、Zephyr はよく同列で比較されますが、実際には同じ抽象レベルの製品ではありません。

問うべきなのは「どれが一番良いか」ではなく、プロジェクトに必要なのが軽量なスケジューリングカーネルなのか、国内 MCU に強い RTOS エコシステムなのか、それともクロスプラットフォームの組み込み OS なのかです。

大まかには次のように整理できます。

FreeRTOS：広く使われるスケジューリングカーネルと AWS 管理の IoT ライブラリ群。
RT-Thread：カーネルに加えて豊富なコンポーネントを持ち、中国語コミュニティと長尾 MCU に強い RTOS。
Zephyr：Linux Foundation 管理の RTOS で、統一サブシステム、デバイスモデル、Devicetree、アプリ再利用を重視する。

まず結論

タスク、キュー、セマフォ、タイマーだけで十分で、リソースも厳しいなら FreeRTOS は今でも安全な選択です。

中国系 MCU を多く使い、BSP、中文資料、ENV、コンポーネントを重視するなら RT-Thread が実用的です。

複数チップ、複数ボード、複数ベンダーでアプリケーションコードを再利用したいなら、学習コストを払ってでも Zephyr を検討する価値があります。

FreeRTOS：軽量で成熟したカーネル

FreeRTOS の強みは、小さく、よく知られ、非常に普及していることです。

FreeRTOS-Kernel はカーネル、移植層、タスク、キュー、セマフォ、イベントグループ、ソフトウェアタイマー、メモリ管理に集中しています。多くの現場で本当に使うのもこの部分です。

AWS による買収後は coreMQTT、coreHTTP、OTA、Device Shadow などの IoT ライブラリも整備され、LTS も用意されています。

ただし FreeRTOS は完全な OS プラットフォームではありません。GPIO、UART、I2C、ピン制御、ボード抽象、HAL 統一は基本的にベンダー SDK またはチーム側の仕事です。

これは欠点ではなく設計選択です。柔軟ですが、チップやボードを変えるとアプリケーション層まで影響を受けやすくなります。

RT-Thread：国内 MCU とコンポーネントに強い

RT-Thread は FreeRTOS より完全な RTOS に近い存在です。

スケジューラだけでなく、ファイルシステム、ネットワーク、デバイスフレームワーク、USB、センサー、パッケージ、ツールが揃っています。AT32、HC32、N32、APM32、HT32、合宙、HPMicro などの長尾 MCU で特に実用的です。

一方で、多くの BSP はまだボード固有、ベンダーライブラリ依存の色が強く、Zephyr のように Devicetree と統一ドライバモデルでアプリを横断的に保つ仕組みとは異なります。

Zephyr：RTOS というより組み込みシステム基盤

Zephyr は複雑ですが、その複雑さは単なる機能追加ではありません。

ベンダー SDK、BSP、HAL、手書きドライバ、設定スクリプト、アプリコードに散らばりがちな要素を、1 つの OS 工程にまとめようとしています。

中心になるのは Kconfig、Devicetree、統一 drivers、subsys、west、CMake、Board / SoC / shield 抽象です。これは小さな組み込み Linux 的な設計思想に近いものです。

Devicetree が重要な理由

Linux では DTB を起動時に渡し、カーネルが runtime に解釈して probe します。MCU では重すぎます。

Zephyr は DTS / overlay をビルド時に処理し、devicetree_generated.h と DT_ マクロに展開します。多くのハードウェア選択がコンパイル時に決まるため、runtime の負担は小さくなります。

これにより、ハードウェア記述とアプリコードが分離され、ボード変更は主に DTS 側で済みます。

アプリケーションコードがきれいになる理由

従来の MCU 工程では、初期化、ピン番号、割り込み、デバウンス、状態機械、イベントキュー、業務ロジックが同じ層に混ざりがちです。

Zephyr では、ハードウェア接続は DTS、機能スイッチは Kconfig / prj.conf、ドライバは主線または module、アプリはイベント処理に寄せる設計になります。

これが多ボード、多チップ、長期保守のプロジェクトで効いてきます。

資源コストは文脈で見る

Zephyr は最小 FreeRTOS より Flash が増えることがあります。ただしそれは統一ドライバ、input、log、device object などの基盤コストです。

機能が少なくボード固定なら FreeRTOS が有利です。外設やボードが増えるほど、Zephyr の基盤コストは再利用されます。

どう選ぶか

固定ハードウェアで、軽量なスケジューリングだけ必要なら FreeRTOS。

国内 MCU、中文資料、BSP、コンポーネントを重視するなら RT-Thread。

複数ボード、複数ベンダー、長期保守、統一ドライバ、Linux 的な設計思想を重視するなら Zephyr。

Zephyr を選ばない方がよい場合

単一ボードで機能が小さい、チームに学習時間がない、対象チップの Zephyr 主線対応が弱い、閉じたベンダー SDK に強く依存している、すでに量産済みで安定している場合は、無理に移行する必要はありません。

まずは主線対応の良い開発ボードで LED、UART、GPIO、input、I2C / SPI を試すのが安全です。

まとめ

FreeRTOS はスケジューリングを解決し、RT-Thread はコンポーネントと国内 MCU エコシステムを補い、Zephyr は MCU ソフトウェア工程そのものを統一しようとします。

小型固定機器なら FreeRTOS、国内 MCU 製品ラインなら RT-Thread、複数プラットフォームと長期保守なら Zephyr が有力です。

参考リンク：

FreeRTOS on KnightLiブログ