IoT アプリケーションは RTOS または Linux を選択します
Linux VS RTOS、どちらを選択すべきですか?
序章
デバイスまたはシステムを開発する場合、最も早くて行う必要がある最も重要な決定の 1 つは、それを実行するオペレーティング システムの種類を決定することです。
オペレーティング システムは、特定のハードウェアに基づく大規模なシステム レベルのソフトウェアであり、リソース管理、スレッド/プロセスのスケジューリング、スレッド/プロセス間通信、同期などのコンポーネントの集合です。
Linux は、Android スマートフォンやスマート TV からゲーム機や自動車に至るまで、多くのデバイスやプロジェクトでデフォルトのオペレーティング システムとして選択されることが多く、多くのデバイスで Linux システムが使用されています。
RTOS (リアルタイム オペレーティング システム、RTOS) も非常に一般的であり、一部の小型ゲートウェイ、スマート ウォッチ、医療機器、玩具では、デバイスのオペレーティング システムとして RTOS が選択されます。
Linux
Linux は汎用オペレーティング システム (汎用オペレーティング システム、GPOS) であり、組み込みシステムにおける Linux のアプリケーションには、通常、周辺機器ドライバーのサポート、ファイル システム、ネットワーク接続、および UI サポートが含まれます。これらはすべて RTOS で提供できます (または機能のこの部分を切り取ってください) が、通常はサポート範囲が広くないか、追加のコストや統合作業が必要になります。
もちろん、Linux のこれらの機能には大量のハードウェアおよびソフトウェア リソースのサポートが必要ですが、RTOS に必要なリソースははるかに少なく、これは必要な金額にも相当します。
もう 1 つの重要な要素は、Linux がリアルタイムではないことです。RTOS は、イベントや割り込みに対する確定的な動作とタイムリーな応答を保証するスケジューリング保証を提供します。
RTOS
RTOS は、外部イベントに対して確定的なハード リアルタイム応答を提供するため、Linux などの従来のオペレーティング システムとは異なります (優先度の高いタスクは、指定された短い時間内に実行する必要があります。そうしないと爆発してしまいます)。一方、従来のオペレーティング システムは、非決定的なソフト リアルタイム応答を提供します。実際には、これは、RTOS ソフトウェアが限られた数のスケジュールされたタスクに対して応答性の高い処理 (従来のオペレーティング システムよりもはるかに高速)を提供できるのに対し、従来の Linux オペレーティング システムは多数の異なるタスクをより効率的に処理できることを意味します。
比較
| Linux | RTOS | |
|---|---|---|
| リアルタイム | ソフト リアルタイム、Linux にはリアルタイム スケジューラを含む多くのスケジューリング オプションがありますが、これはせいぜい「ソフト」リアルタイムであり、リアルタイム Linux の一般的な遅延は数十または数百マイクロ秒のオーダーです。 Linux のような汎用オペレーティング システム (GPOS) 通常、ラウンド ロビンなどの優先タイムシェアリング スケジューラは、多くのプロセス間で時間を「公平に」分散するために使用されます。したがって、実行中のプロセスが増えるほど、それらのプロセスは忙しくなり (利用可能なタイム スライスをより多く使用し)、応答が遅くなります。 | ハード リアルタイム、一般的な RTOS リアルタイム カーネルは、ゼロから数マイクロ秒 (平均時間ではなく最悪の場合) のレイテンシを達成できます。RTOS には通常、プリエンプション優先順位ベースのスケジューラがあるため、最高優先順位の準備完了タスクはとにかくすぐに実行され、タスク自体が一時停止されるか、より優先順位の高いタスクが準備完了になるまで実行を続けます。プログラムを RTOS に配置しても自動的にリアルタイムになるわけではないことに注意してください。開発者は優先順位を適切に割り当てて、すべてのタスクが毎回時間どおりに実行されるようにする必要があります。一般に、実行時間が最も短く、最も確定的なタスクが最も高い優先順位を持つ必要があります。 |
| リソース要件 | 元々、Linux はデスクトップ PC 用に開発されました (x86 プロセッサ アーキテクチャに基づいています)。多くの CPU リソース (おそらく >200MIPS、32 ビット プロセッサ、理想的には MMU を使用)、起動に 4Mb の ROM、16MB の RAM が必要です (数秒かかる場合があります)。通常は 8 ビットまたは 16 ビットでは動作しませんMCU 、および Linux カーネル用にさらに多くのオンボード RAM が必要です。たとえば、ARM Cortex-M アーキテクチャに基づく MCU には通常、数百キロバイトの RAM しか搭載されておらず、これらのチップ上では Linux を実行できません。 | RTOS はミリ秒で起動し、8 ビット以上のマイクロコントローラー上では 10Kb 未満で実行できます。8 ビット アーキテクチャでスケジューラ、通信キュー、セマフォという 2 つのタスクを実行する非常に単純なセットアップには、おそらく約 200 バイトの RAM が必要です。 |
| 安全性 | 高、Linux は適切なプロセス分離を使用しており、アプリケーションは他のプロセスやカーネル自体が使用するメモリにアクセスできません。 | より高い |
| 開発のしやすさ | コードの抽象化がうまく行われているため、移植に便利です。多くのソフトウェアおよびハードウェアドライバー、ますます完璧なデバッグおよびパフォーマンス分析ツールをサポート | 限られたパフォーマンス分析をサポートするデバッグ ツール、コードの互換性は平均的 |
| 理解を深めていくのが難しい | Linux ベースのシステムのブート ローダー、カーネル、およびルート ファイル システムは、RTOS ベースの設計よりも少なくとも数桁複雑です。 | 低い |
| 装置サイズ | より大きい | 小さい |
| 低消費電力 | 消費電力が高くなります。そして消費電力の制御方法がわかりにくい | 低消費電力、シンプルで効果的な消費電力制御方法を提供 |
| 料金 | Linux システムの部品表 (BOM) は約 20 ドルから | シングルチップ マイクロコントローラーの BOM はわずか 3 ドル程度である可能性があります |
| ハードウェアドライバー | Linux は既製のハードウェア ドライバーの支配者であり、最近の多くのチップ ベンダーは Linux ドライバーのみを提供しています。複雑なハードウェア ドライバーを使用している場合は、既製の Linux ドライバーを使用すると大幅に速度が向上します。 | サポートされているハードウェアドライバーは限られています |
| 選択の提案 | リアルタイム パフォーマンスのきめ細かいレベルでは不十分です。ただし、開発者にとって使いやすいという点では、この開発環境は、特に低レベルのコードを深く理解していない人にとっては、はるかに使いやすいものになっています。GPS システムに必要な大規模なデータベースなど、当面のタスクに大量のメモリが必要な場合、Linux の追加メモリは問題になりません。応答時間が人間の知覚に基づいている場合 (遅延が 100 ミリ秒を超えても問題ありません)、リアルタイム パフォーマンスが比較的低くても問題ありません。 | RTOS は、少数のタスク、特に高いリアルタイム要件を持つ少数のタスクのみを同時に実行できます。コードがはるかに少なく、複雑さがはるかに少なく、エラーの可能性がはるかに低いため、システム全体の動作をより詳細に制御できます。安価なハードウェア、高速な応答性、そしてハードな開発作業に取り組む意欲が RTOS の終着点であり、補完的な側面が Linux を示しています。 |
要約する
1) IoT アプリケーションに Linux または RTOS を選択する場合、その単純な答えは次のとおりです。リアルタイムのニーズがある場合は、(名前が示すように) RTOS を使用する必要があります。
2) それ以外は、すべて実際の要件 (コスト、機能) によって異なります。また、開発者の慣れにも大きく左右されます。Linux の構成は非常に難しい場合がありますが、単純な RTOS の方が簡単な場合もあります。
(いいねやコレクションしていただきありがとうございます)