MCUプログラミングにおけるRTOSとベアメタルの利点は？

注：この質問では、2つのRTOSについて具体的に言及していますが、より一般的であり、以前に組み込みRTOSのCコードを記述し、MCUでソフトウェアを直接実行したことがある人なら誰でも回答できます。

組み込みRTOSの詳細を学び、そのためのアプリケーションを作成することに興味があります。現在、EmboxとRIOTを検討しています。それらはオープンソースで、モダンで、アクティブで、優れたドキュメントがあるようです。私の目標は2つのフェーズです。フェーズ1は、これらのOSをコンパイルしてMCU（おそらくAVRまたはARM）にフラッシュする方法を見つけ出すことです。フェーズ2では、単純なCプログラム（基本的にはヘッドレスデーモン）を作成します。これは、「趣味アプリ」として時間とともに進化します。次に、このプログラムを同じMCUにフラッシュ/展開することで、Embox / RIOTとその上にあるアプリで構成されるアプリスタックを正常に展開します。

最終的に行き止まりに至る道を進む前に、C /アセンブラーで書かれMCUにフラッシュされたリアルタイムアプリがRTOSを実際に必要としない理由を説明するのに非常に役立つこの記事を偶然見つけました。 。

だから今、私は本当に混乱していて、コンピューティング理論の私の基本的な理解に疑問を抱いています。私は、最初にEmbox / RIOTを使用するかどうかの決定をしようとしていると思います。

• コースを継続し、両方のOS +アプリのMCUで「アプリスタック」を使用します。または
• 記事の警告に注意し、MCUでアプリ「ベアメタル」を実行してください

明らかに、前者はより多くの作業であるため、そのルートに進むのに十分な理由/報酬が必要です。だから私は尋ねる：これらの（および同様の）組み込みRTOSがMCU / Cアプリ開発者に提供する本当の利点は何ですか？RTOSを使用することで、Cアプリはどのような特定の機能の恩恵を受けることができますか（おそらく、車輪を再発明しないことによって？）RTOSを捨ててベアメタルに移行すると何が失われますか？

ここでは具体的な例を求めています。RTOSのウィキペディアエントリにアクセスしたときに得られるメディアの誇大広告ではありません;-)

マイクロコントローラプログラムは、多くのタスクで構成されています。コンピューター制御の望遠鏡マウントを作りたいとしましょう。タスクは次のとおりです。

• USBシリアルバッファから入力の新しいバイトを取得します。
• 完全なコマンドを受け取ったかどうかを確認します。
• その場合、そのコマンドを実行します。
• 現在の望遠鏡の位置のセンサーを読み取ります。
• 適切な出力を設定して、モーターの次のステップを制御します。

これは、マイクロコントローラーを使用するための非常に一般的なタスクのセットであり、次のような無限ループで管理するのは非常に簡単です。

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

機能を追加および追加し続けると、最終的には、次のような抽象化を作成したい一般的な問題に遭遇し始めます。

• バッファがオーバーフローしているため、タスクがオーバーフローする前に他のタスクを中断できるようにする必要があります。
• 何も必要ないときにスリープしてバッテリーを節約します。
• すべてのタスクが公平に行われるようにする必要があります。readSensors時間がかかりすぎる場合は、中断して後で戻ってくることができます。
• 他のタスクに影響を与えることなく、1つのタスクのみをリセットできるようにする必要があります。
• 1つのタスクでメモリリークまたはその他のバグを発生させて、他のタスクを削除しないようにします。
• 異なるタスクに異なる優先度を与えることができるようにしたい。
• 信頼できないタスクをサンドボックスできるようにしたい。
• さまざまなレートでタスクを実行できるようにします。センサーは1秒間に10回しか読み取れないかもしれませんが、モーターステップを1秒間に100回実行する必要があります。

これらのアイテムの1つまたは2つは、比較的簡単に手動で処理できます。これらの種類の問題が頻繁に発生し、それらをライブラリに一般化できるようになったら、基本的にRTOSを再発明しました。プログラムのタスク管理が非常に複雑な場合、市販のRTOSを使用しなくても、最終的には1つのRTOSの再発明が不十分になります。

しかし、私の経験では、RTOSが必要なラインは、マイクロコントローラーではなくマイクロプロセッサーが必要なラインに非常に近いものです。ファームウェアがそれほど複雑になると予想される場合、通常は最初からマイクロプロセッサのルートに行く方が良いでしょう。

ARM Cortex-M0用の独自の協調マルチスレッドライブラリを作成しました。

それはほんの数ページのコードであり、最初のバージョンの作成とデバッグには1日もかかりませんでした。

Roll-your-ownの大きな利点は、コードを知っていて、RTOSがサポートしていない可能性のあるチップに移植できることです。また、「機能Aと機能Bを同時に使用しようとするとクラッシュしますか？」などの質問について考える時間を短縮できます。コードを書いたので、あなたは答えを知っています。

RTOSから得られる主なものはスレッド化であり、自分で実装することはそれほど大したことではないことがわかりました。RTOSの多くの機能が必要になることはまれです。ただし、要件が不足している場合は、RTOSを使用してください。