ロシアの1つのRTOSの概要、パート8。割り込みの処理

RTOS MAXによる「知識の本」の第1巻の最後の記事を公開しています。 この非公式ガイドが、このRTOSで作業する必要がある場合に、同僚に役立つことを願っています。



前の記事：

パート1.一般情報

パート2. RTOS MAXのカーネル

パート3.最も単純なプログラムの構造

パート4.有用な理論

パート5.最初のアプリケーション

パート6.スレッド同期ツール

パート7.タスク間でデータを交換する手段

パート8.割り込みの処理（この記事）

中断が重要な理由

コンピューターサイエンスの教師は、ポーリングだけでなく中断についての作業があることを非常に好んでいます。その後、彼らは通常、中断の処理の小さな例を挙げて、トピックについて忘れます。 さらに、実際のプログラミングでは、自分のスキンではなく、このビジネスの基本を理解する必要があります。



シングルタスクシステムでプログラミングする場合、尋問機器を操作するために「抜け出す」ことができます。 マルチタスクシステムでは、これはますます困難になっています。



最も単純な例を考えてみましょう。 9600ボーという非常に低い速度でシリアルポートから受信します。 実際の速度は長年250 KBaudの領域にありましたが、問題を解決するために速度を落とすだけではなく、超低速バージョンを考えてみましょう。



シリアルポートには1バイトがあります-これは私のお気に入りのポート設定で10ビットです（8データビット、および開始と停止）。 合計、960バイト/秒です。 1000に切り上げます。これは1ミリ秒あたり1バイトです。 時間軸にイベントを配置します。







典型的なコントローラが次のバイトが到着する前に次のバイトを処理する時間がない場合、ラインから来た新しい値によって上書きされます。 STM32コントローラーの説明から、ダイアグラムでこれの本質を検討してください。







デフォルトでは、タスクは1ミリ秒ごとに切り替えられます。 5つのタスクの順次切り替えの場合を時間軸上に配置しましょう。







タスク1でCOMポートをポーリングします。2つの図を組み合わせてみましょう...







ご覧のとおり、シリアルポートからの4バイトは、それらを待機しているタスクが非アクティブなときに送信されます。 大きなハードウェアキューを持つコントローラーがあります。 たとえば、ESP8266はハードウェアバッファーで128バイトを受信できます。 このようなコントローラで考慮される状況は何もありません-タスク1は、機器によって蓄積されたデータを受け取ります。 ただし、たとえば、すべてのSTM32入力バッファでは、1バイトしか使用できません。 そして、彼らにとって、ポーリングの死のためにマルチタスク環境でシリアルポートを操作することは、9600ビット/秒のようなとんでもない速度でも同様です。



正しい解決策は、バッファメモリに到着したバイトを追加して、処理タスクが大量に蓄積されたすべてを処理するようにすることです。 または、ある種の前処理（たとえば、遅延なしで可能な場合はパケットの初期分析）を実行し、処理済みのパラメーターを処理タスクに転送します。



もちろん、ほとんどの読者に最も近いものとして、シリアルポートを備えた例を選択しました。 実際、シングルタスク環境でもポーリングが受け入れられず、マルチタスク環境では不可能な場合が多くあります。 最初に頭に浮かぶのは、エンジン速度を維持することです。 実際のケースは、エンジンが1回転あたり2回のフィードバックパルスから、毎分最大5,000回転の速度で回転することです。



回転速度を測定するための典型的なアルゴリズムの1つでは、タイマーを使用してこれらのパルスの繰り返し周期を測定する必要があります。 つまり、到着時にタイマーを取り、新しい測定のためにタイマーを再起動する必要があります。 パルスが到着してから読み取り値が取得されるまでにランダムな時間が経過すると、測定精度が大幅に低下します。 たいていの場合、単純に大幅に低下するのではなく、容認できないほど低下します。



状況を推定してみましょう-毎分10,000フィードバックパルス。 60で除算すると、167 Hzになります。 5ミリ秒に1パルス。これは、測定の精度を失わないように、発生した瞬間にできる限り近く処理する必要があります。 インパルスの到着時間を予測することは不可能です-エンジンは彼に満足するように回転します。 5つのタスクの場合、次のタスクへの制御の移行を待つ可能性のある時間は、パルス繰り返し周期の半分以上です。 たとえば、次のような状況です。







インパルスが到着してから調査を実行するタスクが起動するまでにどのくらい時間が経過したかは不明です。 ご覧のとおり、ここでは、割り込みによってのみ、あらゆる種類の合理的なデータ処理を実装できます。 衝動が来て、その到着時刻が記憶されており、すでに処理中のタスクはいつでもこの時間を利用できます。



以上から、

マルチタスク環境での中断は強力なだけでなく、多くの場合、機器を操作するための唯一の可能なメカニズムです。

RTOS MAXで割り込みを処理するための主なメカニズム

RTOS MAXを使用する場合、割り込みは「便利」と「高速」の2つの方法で処理できます。 最初に、メインオプション（「便利」）と見なされるものを検討します。



OS内では、共通のタスクが開発されますが、 Taskから継承するのではなく、 TaskIrqから継承する必要があります。 中断が発生するとすぐに他のすべてのタスクを置き換える必要があるため、このタスクには高い優先順位が与えられます。 TaskIrqクラスには、IrqHandler（）仮想関数が含まれています。これは、割り込みの処理に関連するすべてのアクションをそこに配置することでオーバーライドする必要があります。



初期化中に、割り込みコントローラーのプログラミングを介して割り込みを有効にする必要があります（最後の2つの段落で「割り込み」という言葉が何回言われたかが怖いですが、残念ながらそれなしでは何も起こりません）。 計画タスクを設定するときは、特別なクラスから継承されるため、処理する割り込み要求の数をパラメーターの形式で指定する必要があります。



イデオロギー的に、このタスクの課題は次のように表すことができます。







そのため、優先度を高くする必要があります。他のタスクと変わらないため、それらを置き換える必要があり、これは優先度の助けを借りて行われます。 次に実用的な例を考えてみましょう。 ここに典型的なタスクがあります-シリアルポートに接続された無線モジュールのハンドラー。 ご覧のとおり、実際にはTaskIrqから継承されており、IrqHandler（）関数は実際にブロックされています。









これがこのタスクの追加方法です。

 const int Radio_IrqNumber = EXTI15_10_IRQn; ... result = TaskIrq::Add(radio_task = new PortRadioTask, Radio_IrqNumber, Task::PriorityRealtime);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

無線モジュールの例のNVICセットアップは、このセクションの範囲外です。 私の意見では、この例ではあまり説明的ではありません。 純粋に説明のために、別の例で特定のプロセッサに対してNVICがどのように構成されているかを示します（優先順位を変更することはできませんが、優先順位を変更するオプションは特別に選択されます）。

  NVIC_EnableIRQ(EXTI9_5_IRQn); NVIC_SetPriority(EXTI9_5_IRQn,1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

だから。 タスクが記述され、そのTaskIrq機能がブロックされ、タスクがスケジューラーに追加されます。次は何ですか？ そして-OSのケア。 割り込みが発生すると、内部割り込みハンドラー自体がスケジューラーを呼び出します。 1-タスクをアクティブにします。 ここで重要なのは、タスクの優先度が高く 、他のタスクが混み合うことが保証されることです。 そして、しばらくしてから（タスクを切り替えるために必要）、IrqHandler（）関数が制御を獲得します。 この関数の本体に配置するものは、アプリケーションプログラマの問題です（ドキュメントの次の部分では、下位レベルのドライバを操作するための一般的なソリューションについて説明します）。



標準ソリューション：

• データを受信し、前処理し、通常の優先度のタスクのメッセージキューに入れることができます。
• または、通常の優先度でタスクのセマフォをコックすることが可能です

割り込みハンドラの簡単な例：

 Semaphore s_sema_radio_irq(0, 1); //       void PortRadioTask::IrqHandler() { s_sema_radio_irq.Signal(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインメカニズムの使用時に起こりうる問題

メインの割り込み処理メカニズムを使用することで発生する可能性のある問題はすべて、1つのことに関連しています。ハンドラータスクを起動するには、タスクコンテキストを切り替える必要があります。 時間がかかります。 2つのタスクがあるシステムでの実際の作業では、オシログラムで、切り替えが4.7マイクロ秒で発生したことがわかりました。 一般に、時間はビルドオプション、タスクの数、およびその他の条件に依存します。 さらに推定の基礎として、10マイクロ秒というかなり現実的でかなり丸い値を取りましょう。



マイクロコントローラによって処理される機器の典型的なシナリオをいくつか見てみましょう。 簡単なものから始めましょう。 250キロビットの速度でシリアルポートを介してG-CODEコマンドを受信するCNCマシン。 既に述べたように、シリアルポートでは、バイトは10ビット（8データビットに加えて、開始ビットと停止ビット）です。 合計で、バイト到着率は25 kHzです。 40マイクロ秒で1バイト。 また、コンテキストの切り替えには10マイクロ秒かかります。







マイクロコントローラ（強力な32ビットマイクロコントローラ）の動作時間の4分の1は、コンテキストの切り替えにのみ使用されます。これは、Gコードの行が1つずつ、かなり高密度のストリームになるためです。 これは受け入れられますか？ 可能性が高いはい。



さらに、150 mm / sの速度で印刷する3Dプリンターで1ミリメートルあたり200ステップを必要とするステッピングモーターを使用するには、30 kHzの周波数で動作する必要があります。 これは4分の1以上です。



Gコードは、ステッピングモーターを制御する同じコントローラーで採用されています。 合計すると、割り込みを入力するためにプロセッサ時間の半分以上がすでに必要です。



もちろん、このオプションは受け入れられません 。



しかし、一方で。 同じ速度で同じシリアルポートを使用しますが、32バイトパケットが1秒間に4回送信される無線モジュールに接続します。 したがって、プロセッサの負荷は1200マイクロ秒の長さのセクションで増加し、そのようなピーク負荷の期間は1秒で4800マイクロ秒以内に発生します。 これは時間の4.8％です。 受け入れられますか？ たいていの場合。 つまり、標準的な方法で処理するためのこのオプションは受け入れられると考えています。



同様に、フィードバック信号からエンジン速度を決定するための前述のメカニズムは受け入れられないと推定できます-タイマーは信号が到着した瞬間に可能な限り近づけるべきです。 また、湿度センサーからの読み取り値の取得は完全に受け入れられます。 同時に、シリアルポートからのデータを毎秒921キロビットの速度で処理すると、タスクを切り替えるのに100％の時間がかかるため、受け入れられません...まあなどです。 Acceptable Unacceptableゲームは長時間プレイできます。 一般原則を定式化しましょう。



中断がめったに起こらない場合、このオプションは受け入れられます。



中断が頻繁に発生してコンテキストの切り替えに100％以上かかる場合、このオプションは受け入れられません



コンテキストの切り替えにかかる時間の割合が高い場合、これはめったに起こらず、十分に短いバーストで発生します-オプションは受け入れ可能です。



高周波でのスイッチングが一定の場合、このオプションは受け入れられません。



どのような代替品を提供できますか？ もちろん、直接割り込み処理。

主なメカニズムを拒否すべきではない理由

「すべての場合に直接割り込み処理を提供しないのはなぜですか？」 RTOS MAXの開発者にまったく同じ質問をしました。 残念ながら、彼らの答えは質的でした。標準処理がさらに便利な理由があります。



簡単なものから始めましょう。 割り込みハンドラーの名前。 ARMファミリ内でも、それらは異なります。 STM32とMilanderファミリーの最も顕著な違いは次のとおりです。

STM32	ミランダー
USART1_IRQHandler	UART1_IRQHandler
TIM1_UP_TIM10_IRQHandler	Timer1_IRQHandler
TIM2_IRQHandler	Timer2_IRQHandler

移行中に、それらを書き換える必要があります。 基本的なメカニズムでは、ハンドラーの名前はOSの関心事です。 それらはアプリケーションプログラマから隠されています（ベクトルの名前が隠されていないのは残念ですが、それなしではできません）。



さらに、標準ハンドラーを使用すると、通常のタスクが呼び出されます。 真の割り込みハンドラは、アプリケーションプログラマの目には見えません。 ハンドラータスクを起動し、コンテキストを切り替える必要があることをスケジューラーに通知します。 それ以外はすべて共通のタスクです。 しかし、中断があると、すべてが異なります。 OSの説明（リアルタイムであっても、Windowsであっても）を見ると、非常に多くのメカニズムが割り込みハンドラーで機能しないことがわかります。 RTOS MAXのメカニズムをすばやく調べます。







いくつかのエントリが黄色であると思われる理由を見てみましょう（結局、ある条件下では、メカニズムは利用可能です）が、赤色でマークされています。 これらのメカニズムを実装する場合、関数を再入力する可能性を排除する必要があります。 このため、クリティカルセクションがその中に配置されます。これは、思い出すように、優先度がMAX_SYSCALL_INTERRUPT_PRIORITYよりも低いすべての割り込みをブロックします。 実際、それだけです。 中断は一時的に禁止されています。 つまり、直接割り込み処理の恩恵は受けません。 一方、メインの割り込み処理エンジンで利用可能なすべての設備は失われます。 一般に、メインの割り込み処理メカニズムを直接のメカニズムに優先して拒否する状況では、セマフォを設定できず、メッセージキューを使用できません。 したがって、表では赤でマークされています。

したがって、OSのすべての機能を使用できる場合は、それらを使用する方がより簡単であり、これが極端に必要な場合にのみ割り込みの直接処理に進みます。

直接割り込み処理

直接割り込み処理では、反応速度はマイクロコントローラーの機能によってのみ決定されます。 各プロジェクトで使用可能なstartupXXXX.sファイルから割り込みハンドラーのリストを取得すると便利です。 PinListAndTimerDemoデモアプリケーションは、タイマー2からの割り込みを処理します。ハンドラーの名前をすばやく見つける方法を見てみましょう。



0



ハンドラーの名前がわかれば、次のルールを使用してそれを行うのは非常に簡単です。

• cppファイル（C ++コード）にある場合は、 extern“ C”プレフィックスを追加する必要があります。 これがないと、関数名はC ++ルールに従って形成され、システムは割り込みハンドラを置き換えていることを理解しません。
• 戻り値の型は無効です。
• 引数はありません。

したがって、前述の例では、開始コードのタイマー2からの割り込みハンドラーは次のように名前が付けられています。







そして、処理機能、それぞれ、

 extern "C" void TIM2_IRQHandler (void) { ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような割り込みのハンドラーはできるだけ早く実行する必要があることを覚えておくことが重要です。 プログラムがハンドラーにある間、他のすべてのタスクは機能せず、優先順位の低い割り込みはブロックされます。



割り込みハンドラーは、データをすばやく受け入れ、さらに処理するためにデータを挿入し、すぐに作業を停止する必要があります。 複雑な計算や、割り込みハンドラでのその他の余分な作業を見つける必要はありません。



割り込みをメインタスクに接続するための便利なメカニズムは、リングバッファです。 割り込みは、受信したデータを到着するとそこに入れ、一部のタスクはそれを受け取り、処理速度を気にせずに使用します。

mcucppライブラリのリングバッファー

補助ライブラリとして使用されるKonstantin Chizhovのmcucppライブラリには、すでにリングバッファの実装が含まれています。 ドキュメントの次の部分でライブラリについて多くのことを述べますが、今のところ、ファイルring_buffer.hを考えてみましょう。



RingBufferクラスは、作業でnew演算子を使用して各要素を追加するため、リアルタイムアプリケーション（および特に割り込み）では使用できません。 しかし、同じヘッダーファイルには、RingBufferPO2クラスが含まれています。リングバッファーのサイズは2のべき乗の倍数です。 このクラスは、事前に割り当てられたバッファーで機能するだけでなく、マイクロコントローラーコマンドシステムが許可する「1つのライター、1つのリーダー」スキームに対してスレッドセーフです（危険なカウンターはアトミックアクセスクラスを介して書き込まれ、セキュリティは既にそのクラスによって決定されています）。



クラスは次のように定義されます。



テンプレート<size_t SIZE、クラスT、クラスAtomic = VoidAtomic>

クラスRingBufferPO2



SIZE-要素の数。 2の累乗の倍数でなければなりません。そうしないと、コンパイラーはエラーをスローします。



Tは、保存されるデータのタイプです。 スカラーと構造の両方が許可されます。



Atomic-操作の原子性を保証するクラス（指定されていない場合、原子性は提供されません）。

データを保存するためのバッファは、クラスのメンバー変数です。 したがって、クラスオブジェクトは、十分な空き領域（スタック、ヒープ、グローバルメモリ、特別に定義されたメモリプールなど）があるプールに配置する必要があります。

COMポートから受信したバイトのバッファーの宣言例（64文字）：

 Mcucpp::Containers::RingBufferPO2<64, uint8_t, Mcucpp::Atomic> bufFromUart;     ,   <b>bool push_back(const T& value)</b>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果がfalseの場合、バッファがいっぱいであるため、データは配置されていません。



通常、関数を使用して、キューからデータをプッシュするデータを取得します。 スカラー量の場合、これは正当化されますが、構造の場合-追加のコピー操作が実行されます-データは古い場所から削除されるため、新しい場所にコピーされます。 おそらく、コピーを防ぐために、mcucppライブラリの作成者はわずかに異なる方法を使用しました。 キューからのデータはプッシュされませんが、読み取られます（それらへのリンクが取得されます）。 データを削除するには、別の機能が使用されます。



メインデータ読み取り関数は、次のように呼び出すことができます。



const T＆フロント（）const

T＆バック（）



ご覧のとおり、データへのリンクを返します。つまり、 コピーしません。



キュー内の最新のアイテムへのリンクを取得できます。



const T＆back（）const

T＆フロント（）



インデックスでキューを操作することもできます：



const T＆演算子[]（size_type i）const

T＆演算子[]（size_type i）



さて、要素が不要になったら 、次の関数を使用してキューから削除する必要があります。



bool pop_front（）



キューが空の場合、関数はfalseを返します。



混雑と空のキューをチェックするための補助機能もあります。



bool full（）const

bool empty（）const



現在キューにあるアイテムの正確な数を確認できます。



size_type size（）const



最後に、キューの容量を調べることができます（ただし、一定であり、プログラム開発の段階で設定されますが、動的バッファとの互換性のために、これらの機能が役立つ場合があります）。



size_type max_size（）

size_type容量（）



1つではなく2つの関数を呼び出すアプローチがどれほど悪いかを確認しましょう。 適切なベンチマークを取得するには、コードフラグメントを個別の呼び出しでフレーム化します（対応する行を消します）。









対応するアセンブラコードは次のようになります。









ご覧のとおり、オプティマイザーは関数呼び出しを行わず、すべてを直線的に配置しました。 また、コードの品質は、1つまたは2つの関数があれば違いはありません。 構造を使用する場合、コピーは行われないためです。

リングバッファの例

実際、この例は単純です。 COMポートからのデータをバッファリングする例として考えてください。 ドキュメントの第3部では、COMポートとその割り込みの詳細な操作を検討します。 64要素のバッファーを宣言します（平均30文字の行が処理された場合、そのようなバッファーは確実にオーバーフローしないと直感的に判断しました）。

 #include <ring_buffer.h> #include <atomic.h> ... Mcucpp::Containers::RingBufferPO2<64, uint8_t, Mcucpp::Atomic> bufFromUart;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

割り込みハンドラーで、バッファーにデータを入れます。

 bufFromUart.push_back (Buf[i]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、タスクの1つでは、とりわけ次のようなアクションを実行します。

  while (!bufFromUart.empty()) { char ch = bufFromUart.front(); bufFromUart.pop_front(); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データが上書きされる心配はありません（言うまでもなく、キューのサイズはオーバーフローしないように十分でなければなりません）。 さて、受け取ったキャラクターchでいくつかのアクションを実行します。 キューが空の場合、指定されたループへのエントリは発生しません。

混合割り込み処理

混乱を避けるために、簡単なフレーズから始めます。割り込みの処理を開始するために必要なものはすべて既に説明されています。 他のすべてはすでに曲技飛行です。 おそらく最も正しいことは、最初に2つの極端な方法（ゆっくりと便利に、また迅速に、あまり便利ではない）を習得してから、セクションのこの部分の読み取りに戻ることです。



中断を処理する方法はさまざまです。 最初に、ハンドラーが書き直され、重要なアクションが最初に実行され、次に通常の高優先度タスクがアクティブ化されます。 特に、周波数測定の場合、このハンドラーでは、実際のタイマー値は足からの割り込みの瞬間に取得でき、その後タイマーは次の測定のために開始され、その後、タイマーから受け取った値の処理の問題は通常のタスクに委任されます。 まあ、そして他のもの。 即時の反応が重要であり、コンテキストの切り替えに時間がかかるという事実が重要でない場合は、この方法を使用できます。



そこで、TaskIrqによって生成されたタスクを作成し、独自の割り込みハンドラーを作成し、その中でタイムクリティカルなアクションを実行しました...次に何をしますか？



そして、 MaksIrqHandler（）関数を呼び出す必要があります。 この関数は、コンテキスト切り替えを開始し、割り込み関連関数への制御転送を行います。

仮想割り込み

そして最後に、割り込みに直接関連していないが、割り込みに関連付けられているメカニズムを検討します。 このメカニズムは、必須ではなく、プログラマに追加の表現情報を提供するだけです。



タスクを作成するとき、 TaskIRQ後続クラスに 、実際には存在しない割り込み番号を割り当てることができます。 FIRST_VIRT_IRQ値よりも大きくする必要があります（ARMアーキテクチャの場合、この値は0x100ですが、他のアーキテクチャの場合は異なる場合があります）。



このようなタスクは実際の割り込みに関連付けられておらず、カーネルによって自動的にアクティブ化されることはありません。 ただし、プログラマはいつでも関数を呼び出すことができます。



void ProceedIrq（int irq_num）;



その後、タスクは、中断に関連するタスクのアクティブ化のすべての原則に従ってアクティブ化されます。 なんで？ オプションはおそらく最も素晴らしいです。 たとえば、1つのベクターで複数のデバイスが「ハング」した場合、同じ物理割り込みハンドラーから複数の異なるハンドラータスクを呼び出すことができます（IRQラインの範囲が広くても、コントローラー開発者でさえ呼び出しを組み合わせることができます）。 一般に、OS開発者の1人が説明したように、「メカニズムは寄付されました。なぜ使用しないのですか？」 ProceedIrq（ ）関数は、いずれにしてもシステムの内部ニーズに必要です。



これに関して、中核の検討はドラフトが完了したと見なすことができます。 ドライバーは先行していますが、マニュアルの第2巻ではそれらについて説明しています。