私のシステムは、OS なしで実行できるほどシンプルです。デスクトップ プログラムでイベント リスナーを使用する場合と同じように、割り込みハンドラーを使用するだけです。私がオンラインで読んだものすべてで、人々は割り込みハンドラーに費やす時間をできるだけ少なくし、制御をタスクに戻そうとしています。しかし、私は OS も実際のタスク システムも持っていません。また、OS のないターゲットの設計情報を実際に見つけることはできません。
私は基本的に、USB からデータのチャンクを読み取り、データをメモリに書き込む 1 つの割り込みハンドラーと、データを読み取り、GPIO でデータを送信し、ハードウェア タイマーで再度スケジュールする 1 つの割り込みハンドラーを持っています。
私のように割り込みを使用し、作業階層を管理するために NVIC (私は cortex-M3 を使用) を使用することの何が問題になっていますか?
まず、この質問の文脈で、OS をスケジューラと呼びましょう。
現在、スレッドとは異なり、割り込みサービス ルーチンはスケジューリング スキームの「上」にあります。
つまり、スケジューラはそれらを「制御」できません。
ISR は HW 割り込みの結果として実行に入り、PC をコード セクションの別のアドレスに設定します (より正確には、ISR を呼び出す前に「いくつかのことを行う」割り込みベクトルに)。
したがって、基本的に、ISR の優先度は、優先度が最も高いスレッドの優先度よりも高くなります。
したがって、ISR に費やす時間をできるだけ短くする明白な理由の 1 つは、システム用に設計するスケジューリング方式に ISR が与える「副作用」です。
お使いのシステムは純粋に割り込み駆動型 (つまり、スケジューラもスレッドもありません) であるため、これは問題ではありません。
ただし、ネストされた ISR が許可されていない場合は、割り込みが発生した瞬間から対応する ISR が完了するまで、割り込みを無効にする必要があります。その場合、ISR の実行中に割り込みが発生しても、プログラムは事実上それを無視します。
したがって、ISR 内で過ごす時間が長くなるほど、割り込みを「逃す」可能性が高くなります。
多くのデスクトップ プログラムでは、イベントはキューに送信され、このキューを処理する「イベント ループ」がいくつかあります。このイベント ループはイベントごとに処理するため、あるイベントを別のイベントで中断することはできません。また、イベント ドリブン プログラミングでは、すべてのイベント ハンドラーをできるだけ短くすることをお勧めします。これは、割り込みができないためです。
ベア メタル プログラミングでは、割り込みはイベントに似ていますが、キューには送信されません。
自分でキューを実装し、割り込みによってこれらのキューにフィードし、スーパー ループでこれらのキューを消費することができます (すべての割り込みを無効にしながら消費します)。このアプローチにより、割り込みの順次処理を得ることができます。ハンドラーを短くしておくと、これはほとんど必要なく、ハンドラーで直接作業を行うことができます。
また、OS ベースのシステムでは、キュー、セマフォ、および「割り込みハンドラ タスク」を使用して割り込みを処理することをお勧めします。
ベア メタルでは、分析を行う限り、アプリケーション バウンドまたは割り込み/イベント バウンド向けに設計してもまったく問題ありません。したがって、どのイベント/割り込みがどのレートで発生するかを知っていて、それらすべてを目的の/設計された時間内に処理できることを保証できる場合は、イベント/割り込みハンドラーで迅速に処理するのではなく、確実に時間をかけることができます。フォアグラウンド タスクにフラグを送信します。
もちろん、一般的なアプローチは、フォアグラウンド タスクで物事を処理するのに十分な情報を保存して、すばやく出入りすることです。もちろん、フォアグラウンド タスクは、イベント フラグの検索、優先順位付けなどの車輪を回転させる必要があります。
もちろん、もっと複雑にして、割り込み/イベントが発生したときに状態を保存し、割り込みモードではなくフォアグラウンド モードでフォアグラウンド ハンドラに戻ることもできます。
これはすべて一般的ですが、cortex-m3に固有のものであり、兄のARMのようなモードが実際にあるとは思いません. リアルタイムのアプローチを取り、ハンドラーが決定論的であることを確認し、システムエンジニアリングを行い、応答が決定論的ではない、遅すぎないなど、イベント/割り込みが積み重なる状況が発生しないことを保証する限り長いか物をなくしても大丈夫です
自問しなければならないことは、すべてのイベントがすべての状況で時間内にサービスできるかどうかです。
例えば;
後者の場合、Rate Monotonic Analysis を使用して優先順位を割り当て、最大の応答性を確保できます (実行時間が最も短いハンドラーが最も高い優先順位になります)。最初のケースでは、システムにある程度の決定論が欠けている可能性があり、イベントの負荷とコードの変更の両方でパフォーマンスが変動します。
1 つのアプローチは、ハンドラーをリアルタイムのクリティカル セクションと非クリティカル セクションに分割することです。タイム クリティカルなコードはハンドラーで実行できます。次に、非クリティカル アクションを「バックグラウンド」の非クリティカル セクションで実行するようにフラグを設定します。 -作業を完了するためにイベントフラグまたは共有データを単純にポーリングする「ビッグループ」システムでコンテキストを中断します。多くの場合、割り込みハンドラーで必要なのは、データをコピーしてイベントのタイムスタンプを作成することだけです。これにより、新しいイベントの処理を中断することなく、データをバックグラウンド処理で使用できるようになります。
より洗練されたスケジューリングのために、非常に小さなフットプリントでマルチタスク、同期、IPC、およびタイミングサービスを提供し、非常にローエンドのハードウェアで実行できる、シンプルで低コストまたは無料の RTOS スケジューラが多数あります。ハードウェア タイマーと 10K のコード スペース (場合によってはそれ以下) があれば、RTOS をデプロイできます。
私はあなたの記述された問題を最初に取っています
私が解釈したように、あなたの目標は、USBからコマンドを受信することによって、LED、リレーなどのGPIOを出力するデバイスを作成することです。この単純なタスクでは、アプローチは問題ないようです(USBレイヤーがそれで動作できる場合)十分に）。
ただし、優先順位付けの問題が存在します。この場合、(ケーブルの反対側からのデータで) USB 側を過負荷にし、それを処理する割り込みが、GPIO を処理するタイマーによってトリガーされる割り込みよりも優先度が高くなる可能性があります。 GPIO 側はティックを見逃す可能性があります (他の人が説明したように、割り込みはキューに入れることができません)。
あなたの場合、これは何が考えられるかについてです。
一般的なガイダンス
「割り込みハンドラーでできるだけ時間を費やさない」という理由は、他の人が言ったことです.OSはキューなどを実現するかもしれませんが、ハードウェア割り込みはそのような概念を提供しません。割り込みの原因となるイベントが発生すると、CPU はハンドラーに入ります。次に、そのソースを処理するまで (UART の場合の受信保持レジスタの読み取りなど)、そのイベントの以降の発生は失われます。この時点の後、ハンドラーを終了するまで、イベントが発生したかどうかを受け取ることができますが、回数はわかりません (CPU がまだハンドラーを処理している間にイベントが再び発生した場合、関連する割り込みラインが再びアクティブになります。より優先度の高いものが待機していない場合、CPU はすぐにハンドラーに再び入ります)。
上記では、8 ビット プロセッサと AVR 32 ビット (私はこれらの経験があります) で観察できる一般的な概念について説明しました。
このような低レベル システム (OS なし、1 つの「バックグラウンド」タスク、およびいくつかの割り込み) を設計する場合、各優先度レベルで何が行われるかを理解することが基本です (そのようなシステムを使用する場合)。一般に、最もリアルタイムで重要なタスクを最高の優先度にし、それらのタスクを迅速に提供することに最大限の注意を払いますが、優先度レベルを低くするとよりリラックスできます。
別の側面から、通常は設計段階で、システムが割り込みの失敗にどのように反応するかを計画することができます。通信回線を通過する重要なデータには適切なチェックサムが必要です。特に重要なタイマーは、イベント カウントからではなく、カウント レジスタから取得する必要があります。
割り込みのもう 1 つの厄介な部分は、その非同期性です。関連するロックを適切に設計しないと、最終的には何かが壊れてしまい、デバッグしなければならない可哀想な魂に悪夢をもたらします。また、「割り込みハンドラーに費やす時間をできるだけ短くする」ステートメントは、割り込みコードを適度に短く保つことを奨励しています。これは、この問題について考慮するコードも少なくなることを意味します。RTOS によって支援されるマルチタスクも使用している場合は、この部分を知っておく必要があります (ただし、いくつかの違いがあります: 優先度の高い割り込みハンドラーのコードは、優先度の低いハンドラーのコードに対する保護を必要としません)。
必要な非同期タスクに関してアーキテクチャを適切に設計できれば、(マルチタスクがないという観点から) OS なしで移動する方が、より優れたソリューションであることが証明される可能性さえあります。適切に設計するには、より多くのことを考える必要がありますが、後でロック関連の問題ははるかに少なくなります。私は、単一のバックグラウンド「タスク」で設計された中規模のセーフティ クリティカルなプロジェクトを、中断が非常に少なく、ほとんど中断せずにやり遂げました。それらに関する経験とメンテナンスの要求 (特にバグの追跡) は、社内の他のプロジェクトと比較して非常に満足のいくものでした。マルチタスクの概念に基づいて構築されています。