33

まず背景、私の質問の詳細は次のとおりです。

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

ここで質問があります。上記で説明したことを考えると、どの時点で自分のプロジェクトに RTOS を採用することを検討しますか? 現在、RTOS を使用する理由として、これらの可能性のあるトリガー ポイントを考えています。

  • コードの複雑さ? コードベースのアーキテクチャ/組織はまだ小さいので、すべての詳細を頭の中に入れておくことができます。
  • マルチタスク/スレッディング? 割り込みによるモジュール実行のタイムスライスは、現時点ではマルチタスクで十分です。
  • テスト？ 現在、正式なテストや HW スモーク テスト以降の検証はあまり行っていません (これは近い将来に修正したいと考えています)。
  • コミュニケーション？ 現在、カスタム パケット形式とプロトコルを使用しており、データはバイナリ BLOB であり、START、STOP、SEND DATA コマンドのみを実行します。
  • プロジェクト範囲？ 近い将来、システムを大量生産することを目標に、デバイスをより大きなシステムに統合するプロジェクトを取得する可能性があります. 現在、私たちのすべてのプロジェクトは、一度に 1 つか 2 つのユニットを生産する、約 1 か月の短いターンアラウンドの実験的プロトタイプです。

他にどのような点を考慮する必要があると思いますか? あなたの経験では、ベース ランタイムでコードを実行するだけでなく、RTOS の使用を検討するよう説得した (または強制した) 理由は何ですか? RTOS の設計/プログラミングに関する追加リソースへのポインタも大歓迎です。

4

5 に答える 5

34

RTOS を使用する理由はたくさんあります。それらはさまざまであり、それらがあなたの状況にどの程度適用されるかを言うのは難しい. （注：私はこのように考える傾向があります：RTOSはプリエンプティブカーネルを意味するハードリアルタイムを意味します...）

  • Rate Monotonic Analysis (RMA) - Rate Monotonic Analysisを使用してタイミングの期限が守られるようにする場合は、プリエンプティブ スケジューラを使用する必要があります。

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

  • 複雑さを管理してください -- 確かに、RTOS (またはほとんどの OS フレーバー) がこれに役立ちます。プロジェクトを独立したスレッドまたはプロセスに分解し、メッセージ キュー、ミューテックス、セマフォ、イベント フラグなどの OS サービスを使用して通信および同期できるようにすることで、プロジェクトは (私の経験と意見では) より管理しやすくなります。私は、ほとんどの人が共有リソースを保護するという概念を理解している大規模なプロジェクトに取り組む傾向があるため、多くの初歩的なミスは起こりません。ただし、マルチスレッドのアプローチに移行すると、問題を理解するまで物事がより複雑になる可能性があることに注意してください。

  • サードパーティ パッケージの使用- 多くの RTOS は、プロトコル スタック、ファイル システム、デバイス ドライバー、GUI パッケージ、ブートローダー、その他のミドルウェアなど、他のソフトウェア コンポーネントを提供します。 DIYショップ。

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

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

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

マルチスレッド開発には少し学習曲線があることに注意してください。RTOS/マルチスレッド開発に慣れていない場合は、Choosing an RTOS、The Perils of Preemption、およびAn Introduction to Preemptive Multitaskingに関する記事に興味があるかもしれません。

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

于 2010-09-01T00:56:04.070 に答える
6

RTOS を使用すると、何よりもまず、並列フローを一連のタスクに編成し、それらの間で明確に定義された同期を行うことができます。

IMO、非 RTOS 設計は、すべてのプログラムが 1 つの大きな無限ループである単一フロー アーキテクチャにのみ適しています。マルチフロー (複数のタスクを並行して実行) が必要な場合は、RTOS を使用する方が適しています。RTOS がなければ、この機能を社内で実装することを余儀なくされ、一からやり直さなければなりません。

于 2010-09-02T14:20:53.713 に答える
3

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

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

于 2010-08-31T17:04:15.537 に答える
2

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

  • 標準 C/C++ ライブラリ
  • ブースト ライブラリ
  • ハードウェア固有のサポートを提供できるチップの製造元から入手できるライブラリ
  • 商業図書館
  • オープンソース ライブラリ
于 2010-08-31T17:55:35.003 に答える
1

前述のポイントに加えて、RTOSの使用は、

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

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

于 2010-09-02T14:37:14.690 に答える