2022年最初の投稿は、RTOSとベアメタルを比較します。RTOSを使わないベアメタルMCU開発者が多いと思いますので、RTOS開発メリット/デメリットをベアメタル側から評価、RTOSデバッグツール紹介とベアメタル開発の意味を考えました。
RTOS目的
ルネサスRAファミリのFlexible Software Package構成です。左上Azure RTOSやFreeRTOSの中に、ConnectivityやUSBがあります。これらMCU共有資源を管理するシステムソフトウェアがOSで、PCのWindowsやMac、Linuxと機能的には同じです。
Real-Time性が必要な組込み用OSをRTOSと呼び、FreeRTOSやAzure RTOSが代表的です。これは、IoT MCU接続先が、Amazon Web Services（AWS）クラウドならばFreeRTOSライブラリ、Microsoft AzureクラウドならAzure RTOSライブラリ（図のConnectivity）利用が前提だからです。
※2021年のIoTクラウドシェアは、コチラの関連投稿からAWS>Azure>GCPの順です。
RAファミリに限らず、クラウド接続のIoT MCUは、これらRTOSライブラリを使ったRTOS開発になります。
RTOSメリット/デメリット
例えば、ベアメタルでUSB制御を自作する場合は、USB 2.0/3.0などの種類や速度に応じた作り分けが必要です。ライブラリがあるRTOSなら、USBポートへの入出力記述だけで利用可能です。RTOSが共有資源ハードウェア差を吸収し、アプリケーションが使い易いAPIを提供するからです。
RTOSの資源管理とは、MCUコア/Flash/RAM/周辺回路/セキュリティなどの共有資源を、アプリケーション側から隠蔽（≒ブラックボックス化）すること、とも言えます。
RTOSアプリケーションは、複数タスク（スレッドと呼ぶ場合もあり）から構成され、タスク間の優先制御もRTOSが行います。開発者は、単体処理タスクを複数開発し、それらを組み合わせてアプリケーションを構成します。RTOSアプリケーション例が下図、灰色が開発部分、コチラが関連投稿です。
RTOS利用メリット/デメリットをまとめます。
メリットは、
・RTOSライブラリ利用により共有資源活用タスク開発が容易
・移植性の高いタスク、RTOSアプリケーション開発が可能
・多人数開発に向いている
デメリットは、
・複数タスク分割や優先順位設定など、ベアメタルと異なる作り方が必要
・共有資源、特にRAM使用量がタスク数に応じて増える
・RTOS自身にもバグの可能性がある
簡単に言うと、RTOSとベアメタルは、「開発作法が異なり」ます。
ソフトウェア開発者は、RTOS利用と引換えに、自己流ベアメタル作法を、RTOS作法へ変えることが求められます。RTOS作法は、標準的なので多人数での共同開発が可能です。もちろん、ベアメタルよりもオーバーヘッドは増えます。このため、RTOS利用に相応しい十分なMCUコア能力も必要です。
RTOSタスク開発 vs. ベアメタルアプリケーション開発
最も効果的なRTOS作法の習得は、評価ボードを使って実際にRTOSタスク開発をすることです。弊社FreeRTOSアプリケーションテンプレートは、この例です。
それでも、RTOSタスク開発作法を文章で記述すると、以下のようになります。
開発対象がアプリケーションからタスク（スレッド）へ変わることが、ベアメタルとの一番の違いです。Windowsタスクバーにあるフィルダ表示や、ペイントなどと同様、タスクは、単機能の小さいアプリケーションとも言えます。
このタスクを複数開発し、複数タスクを使ってRTOSアプリケーションを開発します。タスクには、それぞれ優先順位があり、他のタスクとの相対順位で実行タスクがRTOSにより決まります。タスクの状態遷移が、RTOSへの備え：第2回、タスク管理で示した下図です。
ベアメタルアプリケーションとは異なり、優先順位に応じてタスクが実行（Running）され、その実行も、定期的に実行可能状態（Ready）や待ち状態（Suspended）、停止状態（Blocked）へRTOSが変えます。これは、リアルタイムかつマルチタスク処理が、RTOSの役目だからです。遷移間隔などは、RTOS動作パラメタが決めます。
ベアメタル開発は、開発者が記述した通りに処理が実行されますが、RTOS開発のタスク実行は、RTOS任せです。RTOS開発難易度の上がる点が、ここです。
一般的なIoT MCUは、シングルコアですので、実行タスク数は1個、多くの他タスクは、Not Running（super state）状態です。RTOSがタスクを実行/停止/復活させるため、スタックやRAM使用量が急増します。
これら文章を、頭の中だけで理解できる開発者は、天才でしょう。やはり、実際にRTOSタスクを開発し、頭の中と実動作の一致/不一致、タスク優先順位やRTOS動作パラメタ変更結果の評価を繰返すことで、RTOS理解ができると凡人筆者は思います。
ベアメタル開発者が手早くRTOSを理解するには、既にデバッグ済みの複数RTOSタスク活用が便利で、FreeRTOSアプリケーションテンプレートは、この要求を満たしています。概要は、リンク先から無料ダウンロードできます。
文章でまとめたFreeRTOS解説が、コチラの弊社専用ページにあります。また、本ブログ検索窓にFreeRTOSと入力すると、タスク開発例などが参照できます。
RTOSデバッグツール
さて、RTOS作法に則ってタスク開発し、RTOS動作パラメタも適切に設定しても、思ったように開発タスクが動作しない時は、ブラックボックスRTOS自身のバグを疑う開発者も多いでしょう。RTOSのバグ可能性もありえます。
この疑問に対して強力にRTOS動作を解析できるFreeRTOSデバッグツールがあります。資料が無料でダウンロードできますので、紹介します。
※このツールを使うまでもなく、弊社FreeRTOSアプリケーションテンプレートは、正常動作を確認済みです。
まとめ：RTOS vs. ベアメタル
IoT MCUのクラウド接続 → 接続クラウド先のRTOSライブラリ必要 → RTOSライブラリ利用のRTOS開発が必要、という関係です。
RTOS開発は、ベアメタルと開発作法が異なる複数タスク開発です。タスクは、優先順位に応じてRTOSがMCU処理を割当てます。また、MCU共有資源がRTOSアプリケーションから隠蔽されるため、移植性が高く多人数での大規模開発にも向いています。
一方で、RTOSオーバーヘッドのため、ベアメタルよりも高いMCU能力が必要です。
シングルコアMCUでは、RTOSとベアメタルのハイブリッド開発は困難です。開発者がRTOSを利用するなら、慣れたベアメタル開発から、RTOSタスク開発への移行が必要です。
ベアメタル開発経験者が、効果的にRTOSタスク開発を習得するには、評価ボードと複数RTOSタスクが実装済みの弊社RTOSアプリケーションテンプレートの活用をお勧めします。
ベアメタル開発意味
RTOSのタスク処理待ち（セマフォ/Queue）を使うと、ベアメタルよりも排他/同期制御が簡単に記述できます。それでも、全てのMCU開発がRTOSへ移行することは無いと思います。様々なセンサデータをAD変換するエッジMCUは、ベアメタル開発、エッジMCUを複数個束ねクラウドへ接続するIoT MCUは、RTOS開発などがその例です。
MCU開発の基本は、やはりRTOS無しの「ベアメタル開発」です。
ベアメタル開発スキルを基にRTOSを利用してこそ、RTOSメリットを活かしたタスクやアプリケーション開発ができます。共有資源ブラックボック化、多人数開発のReal-Time OSは、「ベアメタル開発の補完」が起源です。
PC OSとは全く逆のこの生い立ちを理解していないと、効果的なRTOS利用はできません。近年MCU性能向上は著しいのですが、向上分をRTOSだけに振り分けられる程余裕はなく、IoTセキュリティなどへも配分する必要があります。
この難しい配分やRTOS起因トラブルを解決するのが、ベアメタル開発スキルです。弊社マイコンテンプレートは、主要ベンダのベアメタル開発テンプレートも販売中、概要ダウンロード可能です。
組込み開発 基本のキ：バックナンバー
2022年最初の投稿に、筆者にしては長文すぎる（!?）のRTOS vs. ベアメタルを投稿したのは、今年以降、RTOS開発が急速に普及する可能性があるからです。
クラウド接続からRTOS必要性を示しましたが、セキュリティなど高度化・大規模化するIoT MCU開発には、移植性の高さや多人数開発のRTOSメリットが効いてきます。
また、半導体不足が落ち着けば、RTOS向き高性能MCUの新しいデバイスが、各ベンダから一気に発売される可能性もあります。スマホ → 車載 → IoT MCUが、半導体製造トレンドです。
※現状のMCUコア関連投稿が下記です。
Cortex-M33とCortex-M0+/M4の差分
Cortex-M0からCortex-M0+変化
Cortex-M0/M0+/M3比較とコア選択
IoT MCU開発が複雑化、高度化すればする程、前章のベアメタル開発や、組込み開発の基礎技術：基本のキの把握が、開発者にとって益々重要になります。
組込み開発、基本のキ：バックナンバーを示します。年頭、基本を再確認するのはいかがでしょう？
組込み開発 基本のキ：組込み処理
組込み開発 基本のキ：IoT MCUセキュリティ