1

クライアントから提供された、カスタマイズされた独自の RTOS に取り組んでいます。

RTOS は、優先プリエンプションを伴うラウンド ロビン スケジューリングを使用します。

シナリオは -

  1. Renesas H8S コントローラは 20 MHz で動作しています
  2. イーサネット割り込みの割り込みを構成しました (LAN9221 チップが割り込みを行っています)
  3. LAN コントローラからデータを読み取る OS タスクは、OS で最優先で実行されています。
  4. システムで 2 番目に優先度の高い別の OS タスク TCP
  5. ウォッチドッグを参照する OS タスク

ネットワーク上の爆撃状態をシミュレートするために、ネットワーク トラフィックを生成しました。問題は、イーサネットのデータ レートが高い (500 パケット/秒を超える) 場合です。1 秒間に設定された ISR ウォッチドッグが起動されます。

ウォッチドッグは、OS 機能の問題を検出するために、OS の優先度の低いタスクによってサービスされるように構成されています。

ISR の頻度と優先度の高いタスクがウォッチドッグ タスクをスケジュールできないとは思えません。私の疑いを確認するために、私は ISR 自体でウォッチドッグにサービスを提供し、2000 パケット/秒まで動作することを発見しました。

より高いデータ/割り込みレートでもウォッチドッグが起動しないように、状況を処理する方法を提案してください。

ウォッチドッグは、通常の OS 優先度で実行されている OS タスクで更新され、無限ループをキャッチするのに役立ちます。

OS 優先度が最も高いタスクは、Ethernet パケット読み取りタスクです。イーサネットがパケットを受信したときに発生するハードウェア割り込みが 1 つあります。ISR では、待機中のイーサネット パケット読み取りタスクをスケジュールします。

また、私のシステムでは、タイマー割り込みを使用して OS が実行されていません (他の OS の実行と同様)。OS はラウンド ロビンであり、自発的に制御を放棄します。そのため、ウォッチドッグ タスクの優先度を通常よりも高くすることはできません。そうしないと、OS は常に優先度が高く、準備ができていることを検出し (ウォッチドッグはイベントを待機せずに無限ループで更新されます)、他のタスクを実行する時間がありません。何らかのイベントを待っているタスクだけが高い優先度を持つことができます。

したがって、問題は、頻繁な割り込みと優先度の高いタスク (イーサネット パケットの読み取り) の継続的なスケジューリングのために、ウォッチドッグ タスクがリフレッシュする時間がないことです。

4

4 に答える 4

4

ウォッチドッグの優先順位を高くするようにしてください。

これは一見間違っているように見えるかもしれません。ウォッチドッグの優先度を高くするべきではありませんが、これは負荷が高くないシステムにのみ当てはまります。負荷が高いと、スケジューリングによってウォッチドッグが押し戻され (結局のところ優先順位が低い)、誤ったタイムアウトが発生する可能性があります。

ウォッチドッグに高い優先度を与えても、パフォーマンスに大きな影響はありません (小さなタスクであり、頻繁には実行されず、割り込みによってトリガーされます) が、枯渇しないようにします。

欠点は、エンドレス ループをキャッチできなくなることです (ウォッチドッグによってループが中断される可能性があるため)。

また、不適切に設計されたハードウェアまたは割り込みの不適切なマッピングも考慮する必要があります。おそらく、ウォッチドッグ IRQ にネットワーク カードよりも高い優先度を与えることができます。これにより、タスクに高い優先度を与えることなく、ウォッチドッグがタイムリーに割り込みを処理できるようになります。

または、ネットワーク パケットが処理されたときにカウンターをインクリメントすることもできます。新しい優先度の高いウォッチドッグ スレッドは、このカウンターを監視し、カウンターが変化する限り優先度の低いウォッチドッグ タスクが起動しないように再構成できます。

于 2012-05-21T08:35:50.193 に答える
1

In any form of real-time application you need, by definition, to be 100% aware of what is going on. You must know how much time each task consumes. Measure the time needed for each task with an oscilloscope by toggling a pin. Then calculate these times for the whole system. If the higher priority tasks take too much time, well, then obviously the dog will starve.

If this is too complex to measure because of acyclic or non-deterministic behavior, the program needs to be fixed. If the watchdog sits in a high priority task, you have pretty much disabled it for any task with lower prio. You might as well shut the watchdog off entirely then.

Trial & error patches, giving the watchdog higher prio, or increasing the CPU clock until the bug goes away is simply not a professional approach.

But then of course, the hardware might not be sufficient to service such a high data load as you expect. Then you may have no other option but to either use dirty patches or re-design the product from scratch with a suitable MCU.

于 2012-05-22T06:45:21.030 に答える
0

おそらく、それを行う方法を伝えることは問題ではなく、説明したアーキテクチャが機能するはずです。あなたがする必要があるのは、ウォッチドッグがサービスされていない理由を発見することです.

RTOS にデバッグおよびテスト用の計測器またはツールがない場合は、ウォッチドッグ ループに I/O トグルを追加し、スコープで監視できます。トグルが停止するすべての期間は、優先度の高いタスクまたは割り込みが実行されている場所です。それが 1 秒以上続くと、ウォッチドッグがトリガーされます。次に、他のタスクと ISR に同様の計測を追加して、何が時間を取っているかを確認できます。

システムが実際に失敗するように、高負荷でデッドロックしている可能性はありますか? ウォッチドッグの起動が完全に有効な状況。実際にシステム障害を検出している場合は、起動を停止したくありません。システム障害を修正したいのです。

于 2012-05-21T18:23:45.050 に答える
0

ネットワーク パケットを処理するタスクが非常に多くの時間を消費し、ウォッチドッグを更新するタスクが CPU 時間を取得できない場合。その場合、システムは高いネットワーク負荷を処理できません。ウォッチドッグの問題は、この「高いネットワーク負荷を処理できない」問題の症状にすぎません。

解決策は、より高速な CPU を使用する、ネットワークを遅くする、パケット処理のオーバーヘッドを減らす、またはこれらのオプションを組み合わせることです。システムが高いネットワーク負荷を処理できるように (また、ウォッチドッグを更新するタスクが実行されるように)。「高いネットワーク負荷の処理」には、パケットのドロップが含まれる場合があることに注意してください。これは、ネットワークの輻輳を処理するための通常の/確立されたアプローチです。

于 2012-05-21T18:57:38.763 に答える