web-dev-qa-db-ja.com

RTOS vs MCUプログラミングのベアメタルの利点？

ご注意ください：この質問は2つのRTOSについて具体的に言及していますが、より一般的であり、以前に組み込みRTOS用のCコードを記述していて、それらのソフトウェアはMCUで直接実行されます。

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

最終的に行き止まりに至る道を進む前に、私は偶然偶然に遭遇しました この記事 これは、C /アセンブラーで記述され、MCUにフラッシュされたリアルタイムアプリが、なぜ不要なのかを説明するのにかなり役立ちます'treallyそれらの下にRTOSが必要です。

だから今、私は本当に混乱しており、コンピューティング理論に関する私の基本的な理解の一部に疑問を投げかけています。そもそもEmbox/RIOTを使うかどうかの決定をしようとしていると思います。

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

明らかに、前者の方が手間がかかります。そのため、そのルートに進むには正当な理由/見返りがあるべきです。だから私は尋ねます：これらの（および類似の）組み込みRTOSがMCU/Cアプリ開発者に提供する実際の利点は何ですか？ RTOSを使用することで、Cアプリが（おそらく、ホイールを再発明しないことによって）どのような特定の機能を利用できますか？ RTOSを捨ててベアメタルにすることで何が失われますか？

RTOSのウィキペディアエントリにアクセスしたときに表示されるメディアの誇大宣伝ではなく、ここで具体的な例を求めています;-）

coperating-systemsreal-timearm
11
smeeb

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

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

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

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

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

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

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

ただし、私の経験では、RTOSを必要とする行は、マイクロコントローラーではなくマイクロプロセッサーを必要とする行に非常に近くなっています。ファームウェアがそのように複雑になることが予想される場合は、通常、最初からマイクロプロセッサのルートに進みます。

11
Karl Bielefeldt

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

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

あなた自身のロールの大きな利点は、コードを知っていて、RTOSがサポートしていない可能性のあるチップに移植できることです。また、 "will it ' crash機能AとBを同時に使用しようとしていますか？」コードを記述したので、答えはわかっています。

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

7
Atsby