web-dev-qa-db-ja.com

組み込みプロジェクトにRTOSを使用することを検討するのはなぜですか？

最初に背景、私の質問の詳細は次のとおりです。

私が取り組んでいるプラットフォームで働いている会社は、現在、MPLAB IDEを開発環境として使用しているMicrochipPIC32ファミリです。以前はMicrochipdsPICおよびTIMSPのファームウェアも作成しました。この同じアプリケーションのファミリ。ファームウェアは、コードがデバイス制御、データサンプリング、ユーザー通信（通常はユーザーPC）の3つのメインモジュールに分割されているという点で非常に単純です。デバイス制御は、GPIOバスラインとSPIまたはI2C制御が必要な少なくとも1つの部品。データサンプリングは、ファームウェアモジュールを使用して割り込み駆動され、サンプル周波数を維持し、さらに多くのSPI/I2CおよびGPIOバスラインを使用してサンプリングハードウェア（ADCなど）を制御します。 ）ユーザー通信は現在、Microchip AppFrameworkを使用してUSB経由で実装されています。

さて、質問です。上記で説明したことを考えると、どの時点でプロジェクトにRTOS）を採用することを検討しますか？現在、これらの考えられるトリガーポイントを使用する理由として考えています。 RTOS：

  • コードの複雑さ？コードベースのアーキテクチャ/組織はまだ十分に小さいので、すべての詳細を頭の中で保持できます。
  • マルチタスク/スレッド？今のところ、マルチタスクには割り込みによるモジュール実行のタイムスライスで十分です。
  • テスト？現在、HWスモークテスト（修正したいこと）を過ぎて、正式なテストや検証はあまり行っていません。近い将来）。
  • Communication？現在、カスタムパケット形式と、START、STOP、SENDDATAコマンドのみを実行するプロトコルを使用しています。データはバイナリブロブです。
  • プロジェクトの範囲？近い将来、デバイスをに統合するプロジェクトを取得する可能性があります。そのシステムを大量生産することを目的としたより大きなシステム。現在、私たちのプロジェクトはすべて実験的なプロトタイプであり、約1か月の短納期で、一度に1つまたは2つのユニットを生産しています。

他にどのような点を考慮すべきだと思いますか？あなたの経験では、RTOSとベースランタイムでコードを実行するだけではなく）の使用を検討することを納得（または強制）しましたか？RTOSも大歓迎です。

embeddedrtosfirmware
29
spade78

RTOSを使用する理由はたくさんあります。それらは多様であり、それらがあなたの状況にどの程度当てはまるかはわかりません。 （注：私はこのように考える傾向があります：RTOSimplieshard real time whichimpliesプリエンプティブカーネル...）

  • レートモノトニック分析（RMA）-使用する場合 レートモノトニック分析 タイミングの期限が守られていることを確認するには、プリエンプティブスケジューラを使用する必要があります

  • リアルタイムの期限を守る-RMAを使用しなくても、優先度ベースのプリエンプティブRTOSを使用すると、スケジューラーは期限を確実に守ることができます。逆説的ですが、RTOSは通常、割り込みがマスクされるカーネルの クリティカルセクション が原因で 割り込みレイテンシ 増加します

  • 複雑さの管理-間違いなく、RTOS（またはほとんどのOSフレーバー）がこれに役立ちます。プロジェクトを許可することによって独立したスレッドまたはプロセスに分解され、メッセージキュー、ミューテックス、セマフォ、イベントフラグなどのOSサービスを使用して通信および同期することで、プロジェクト（私の経験と意見では）がより管理しやすくなります。大規模なプロジェクトでは、ほとんどの人が共有リソースの保護の概念を理解しているため、ルーキーのミスは多く発生しませんが、マルチスレッドアプローチに移行すると、頭を抱えるまで事態が複雑になる可能性があることに注意してください。問題。

  • サードパーティパッケージの使用-多くのRTOSは、プロトコルスタック、ファイルシステム、デバイスドライバー、GUIパッケージ、ブートローダーなどの他のソフトウェアコンポーネントを提供します。 DIYショップというよりも「インテグレーター」になり、アプリケーションをより迅速に構築するのに役立つミドルウェア。

  • Testing-はい、確かに、特に一貫したアプローチが使用されている場合は、制御の各スレッドを明確に定義されたインターフェイスを備えたテスト可能なコンポーネントと考えることができます（メッセージキューの1か所で常にブロックするなど）。もちろん、これはユニット、統合、システムなどのテストに代わるものではありません。

  • 堅牢性/フォールトトレランス-RTOSは、プロセッサのMMU =（PICの場合、これは当てはまらないと思います）。これにより、各スレッド（またはプロセス）を独自の保護されたスペースで実行できます。スレッド/プロセスは、互いのメモリに「ディップ」して踏みつけることはできません。デバイス領域（MMIO）は、一部（またはすべて）のスレッドに対して立ち入り禁止になっている可能性があります。厳密に言えば、プロセッサのRTOSを活用するために、MMUは必要ありません。 （またはMPU）ですが、2つは連携して非常にうまく機能します。

一般に、RTOS（またはある種のプリエンプティブマルチタスカー）を使用して開発できる場合、結果はよりクリーンで、よりモジュール化され、より適切に動作し、より保守しやすくなる傾向があります。オプション、私は1つを使用します。

マルチスレッド開発には少し学習曲線があることに注意してください。 RTOS /マルチスレッド開発に不慣れな場合は、 RTOSの選択 、 プリエンプションの危険性 および プリエンプティブの概要）に関するいくつかの記事に興味があるかもしれません。マルチタスク 。

最後に、推奨事項を求めていなくても...多数の商用RTOSに加えて、無料の製品（ FreeRTOS 最も人気のあるものの1つ）と （ Quantum Platform は、プリエンプティブカーネルを含む アクティブオブジェクト の概念に基づくイベント駆動型フレームワークです。 たくさんの選択肢 がありますが、特にデバッグ時に、ソースコードがあると（RTOSが無料でなくても）有利であることがわかりました。

33
Dan

RTOSは、何よりもまず、並列フローをタスクのセットに編成し、それらの間で明確に定義された同期を行うことを可能にします。

非RTOS設計であるIMOは、すべてのプログラムが1つの大きなエンドレスループであるシングルフローアーキテクチャにのみ適しています。マルチフロー（多数のタスクを並行して実行する）が必要な場合は、RTOSの方が適しています。 RTOS）がないと、この機能を社内で実装し、車輪の再発明を行う必要があります。

6
Ilia

コードの再利用-RTOS APIを使用してドライバー/プロトコルハンドラーをコーディングすると、将来のプロジェクトに簡単にプラグインできる可能性があります

デバッグ-一部のIDE（IAR Embedded Workbenchなど）には、タスクのCPU使用率やスタック使用率など、実行中のプロセスに関する適切なライブデータを表示するプラグインがあります。

3
Doug Currie

通常、リアルタイムの制約がある場合はRTOSを使用します。リアルタイムの制約がない場合は、通常のOSで十分な場合があります。RTOS/ OSはランタイムを提供します。メッセージキューやタスクなどのインフラストラクチャ。複雑さを軽減し、低レベルのサポートを提供し、テストを支援できるコードを探しているだけの場合は、次のライブラリのいくつかで実行できます。

  • 標準のC/C++ライブラリ
  • ブーストライブラリ
  • ハードウェア固有のサポートを提供できる、チップの製造元から入手可能なライブラリ
  • 商業図書館
  • オープンソースライブラリ
2
waffleman

前述のポイントに加えて、RTOS）を使用すると、サポートが必要な場合にも役立つことがあります。

  • 標準ストレージデバイス（SD、コンパクトフラッシュ、ディスクドライブ...）
  • 標準通信ハードウェア（イーサネット、USB、Firewire、RS232、I2C、SPI、...）
  • 標準通信プロトコル（TCP-IP、...）

ほとんどのRTOSはこれらの機能を提供するか、それらをサポートするために拡張可能です

1
chrmue