ロシアの1つのRTOSの概要、パート7。タスク間でデータを交換する手段

相互ロックのレベルでの相互作用に加えて、タスクは相互に、およびデータレベルで相互作用する必要があります。 同時に、MAXシステムの際立った特徴は、同じコントローラー内でデータを交換できるだけでなく、


図 1. 1つのコントローラー内でのタスクの相互作用の例

コントローラー間でも、トランスポート層を完全に隠します。


図 2.コントローラー間のタスクの相互作用の例

さらに、メモリが完全に分離されているため、異なるコントローラは異なるプロセスと同等です。 当社のウェブサイトで公開されているOSバージョンでは、コントローラー間の物理チャンネルは、有線SPIまたはUARTインターフェース、およびRF24無線モジュールを介したワイヤレスインターフェースにすることができます。

SPIおよびUARTオプションを使用することは推奨されません。現在の実装では、それらを介して接続できるコントローラは2つまでです。

さらにこれについてさらに説明します。「知識の本」の他の章はここにあります。

パート1.一般情報
パート2. RTOS MAXのカーネル
パート3.最も単純なプログラムの構造
パート4.有用な理論
パート5.最初のアプリケーション
パート6.スレッド同期ツール
パート7.タスク間でデータを交換する手段（この記事）
パート8.割り込みの処理

1つのコントローラー内でデータを交換する手段（メッセージキュー）

RTOSの操作に対する古典的なアプローチは次のとおりです。タスクはメッセージキューを使用して相互にデータを交換します。 少なくとも、それはすべての学術教科書が要求するものです。 私は実用的なプログラマーに属しているため、特定のケースのために作成された直接的な交換手段を使用する方が簡単な場合があることを認めています。 たとえば、システムに関連付けられていない通常のリングバッファ。 しかし、それでも、メッセージキューが最適なオブジェクトである場合があります（システム以外のものとは異なり、ポーリングされるバッファがいっぱいまたは空のときにタスクをブロックできるためです）。

教科書の例を考えてみましょう。 シリアルポートがあります。 もちろん、回路によって、システムを簡素化するために、フロー制御ラインなしで作られています。 ワイヤ上のデータは次々に送られます。 同時に、多くの（すべてではありませんが）標準コントローラーの機器は、大きなハードウェアキューを意味しません。 データを収集する時間がない場合は、受信シフトレジスタからの新しい部分でデータが消去されます。

一方、データを処理するタスクに時間がかかるとしましょう（たとえば、作業ツールを移動するなど）。 これは非常に正常です-CNCマシンのGコードには一定のリードがあります。 ツールが移動し、同時に次の線がワイヤを通ります。

コントローラのバッファレジスタがオーバーフローせず、プログラム内のバイトがメイン操作中に受信される時間があるため、割り込みハンドラで受信する必要があります。 生のバイトがメインタスクに転送される場合、最も簡単なオプションが可能です。


図3

ただし、この場合、キューの配置と取り出しの操作が多すぎることがわかります。 オーバーヘッドが高すぎます。 生のバイトではなく、前処理の結果をキューに入れることをお勧めします（行から開始し、Gコードでこの例の行を解釈した結果で終了します）。 ただし、割り込みハンドラーでの前処理は受け入れられません 。その時点で、優先度設定に応じて他のすべての割り込みがブロックされ、他のサブシステムのデータが遅延して処理され、製品の動作が中断されることがあるためです。

この仮定はそれを数回繰り返す価値があります。 あるフォーラムで、「PDM形式のマイクサウンド用に標準のアンパッカーを使用しましたが、正常に機能しません」という質問を見ました。 また、質問に例が添付され、PDMフィルタリングが割り込みのコンテキストで実行されました。 質問の作成者が中断せずにPDMからPCMに変換し始めたとき（彼がすぐにアドバイスされたように）、すべての問題が自然に消えたことは言うまでもない。 したがって、 中断時には、前処理は受け入れられません！ 電子レンジで卵を調理したり、割り込みハンドラーで不要なアクションを実行したりしないでください ！

前処理がある場合、すべての教科書で推奨されるスキームは次のとおりです。


図4
高優先度の前処理タスクは、ほとんど常にブロックされます。 割り込みハンドラがハードウェアからバイトを受信し、プリプロセッサが起動してこのバイトを渡し、その後に去りました。 これ以降、すべての割り込みが再び有効になります。

高優先度のプリプロセッサが起動し、内部バッファにデータを蓄積してからスリープ状態になり、再び通常の優先度でタスクを処理する機会が与えられます。 行が蓄積されると（改行文字が到着します）、それを解釈し、結果をメッセージキューに入れます。 これはすべての学術出版物が推奨するオプションなので、ここで読者に古典的なアイデアを伝える必要がありました。 ただし、理論家としてではなく、実践者として私自身をすぐに追加します。この方法の弱点がわかります。 キューへのまれな呼び出しで勝ちますが、優先度の高いタスクに入るためのコンテキストスイッチで負けます。 一般に、このアプローチの欠点について説明されていますが、実際の作業方法については推奨事項が説明されています。パフォーマンスとシンプルさの最適な比率を選択して、誰もが独自の方法を見つける必要があります。 実際の見積もりを伴ういくつかの推奨事項は、中断に関する次の記事に記載されます。

メッセージキューを実装するには、MessageQueueクラスを使用します。 メッセージキューは任意のタイプのデータで効果的に機能する必要があるため、テンプレートとして設計されています（引数としてデータタイプが置き換えられます）。

template <typename T> class MessageQueue { ... 

コンストラクターの形式は次のとおりです。

MessageQueue（size_t max_size）;

max_sizeパラメーターは、キューの最大サイズを決定します。 容量がいっぱいになったときに要素をキューに入れようとすると、空きスペースができるまでタスクがブロックされます（一部のタスクは、既にキューにある要素の1つを使用しません）。

あまりにも多くのことがすでに述べられているので、ここではキューの初期化の例をせずにはできません。 キュー要素のタイプがshortであり、キューの次元が5要素を超えないことが明らかなテストフラグメントを取得します。

 voidMessageQueueTestApp::Initialize() { mQueue = new MessageQueue<short>(5); Task::Add(new MessageSenderTask("send"), Task::PriorityNormal, 0x50); Task::Add(new MessageReceiverTask("receive"), Task::PriorityNormal, 0x50); } 

関数を使用してメッセージをキューに入れることができます：

結果プッシュ（定数Tおよびメッセージ、uint32_t timeout_ms = INFINITE_TIMEOUT）;

キューがいっぱいの場合、timeout_msパラメーターが必要です。 この場合、システムは空き領域が表示される瞬間を待ちます。 そして、このパラメーター-待機が許可される量を伝えます。

必要に応じて、メッセージをキューの最後ではなく、最初に置くことができます。 これを行うには、次の関数を使用します。

結果PushFront（const T＆メッセージ、uint32_t timeout_ms = INFINITE_TIMEOUT）;

キューの先頭から次の要素を削除するには、次の関数を使用します。

結果ポップ（T＆メッセージ、uint32_t timeout_ms = INFINITE_TIMEOUT）;

ここで、それぞれタイムアウトパラメータは、キューが空の場合の待機時間を設定します。 設定された時間の間、システムは、他のタスクによってキューに入れられたメッセージが表示されるのを待ちます。

要素を削除せずに、キューの先頭から要素の値を取得することもできます。

結果のピーク（T＆メッセージ、uint32_t timeout_ms = INFINITE_TIMEOUT）;

最後に、キューに入っているメッセージの数を調べる関数があります。

size_tカウント（）

および可能な最大キューサイズ：

size_t GetMaxSize（）

異なるコントローラー間の通信手段

実際、純粋に形式的には、コントローラー間でデータを交換する手段はドライバーです。 しかし、イデオロギー的に、それらはデータ交換の通常の手段に関連しています。これはMaxの主な機能の1つです。

OSの公開バージョンでは、有線UARTまたはSPIインターフェース、またはRF24無線モジュール（SPIインターフェースに接続されている）を介して物理的な交換を実行できることを思い出してください。 また、コントローラー間のデータ交換をアクティブにするには、MaksConfig.hファイルに次の行を入力する必要があることを思い出してください。

#define MAKS_USE_SHARED_MEM 1

定数の1つを1に設定して、物理チャネルのタイプを決定します。

MAKS_SHARED_MEM_SPI、MAKS_SHARED_MEM_UART、またはMAKS_SHARED_MEM_RADIO

現在の実装のSPIおよびUARTメカニズムは2つのデバイスのみの接続を提供するため、無線オプションが推奨されます

さて、このような長引いた前文の後、SharedMemoryクラスの調査を始めましょう。
クラスオブジェクトは、Initialize（）関数を使用して初期化できます。 「缶」という言葉は偶然使用されません。 一般に、ラジオオプションの場合、初期化は必要ありません。

データ構造はこの関数に渡されます。 そのフィールドについて簡単に考えてみましょう。



この構造体を埋めて初期化関数を呼び出す例を検討してください。

  SmInitInfo info; info.TransferCore = &SpiTransferCore::GetInstance(); info.NotifyMessageReceived = true; info.AutoSendContextsActivity = true; info.SendActivityDelayMs = 100; info.CheckActivityDelayMs = 200; SpiTransferCore::GetInstance().Initialize(); SharedMemory::GetInstance().Initialize(info); 

別のオプション：

  SmInitInfo info; info.TransferCore = &SpiTransferCore::GetInstance(); info.AutoSendContextsActivity = true; info.SendActivityDelayMs = 100; info.CheckActivityDelayMs = 200; SpiTransferCore::GetInstance().Initialize(); SharedMemory::GetInstance().Initialize(info); 

このクラスは、タスクの相互作用のための2つのメカニズム-メッセージと共有メモリ（ブロッキングの可能性あり）を提供します。

共有メモリオブジェクトは常に1つであるため、オペレーティングシステムの開発者は、複雑な関数名をグローバルな名前に変換するMaksSharedMemoryExtensions.cppファイルを作成しました。

このファイルのスニペットは次のとおりです。

 Result GetContext(uint32_t context_id, void* data) { return SharedMemory::GetInstance().GetContext(context_id, data); } Result GetContext(uint32_t context_id, void* data, size_t data_length) { return SharedMemory::GetInstance().GetContext(context_id, data, data_length); } Result SetContext(uint32_t context_id, const void* data, size_t data_length) { return SharedMemory::GetInstance().SetContext(context_id, data, data_length); } 

配信パッケージに含まれるすべてのアプリケーションはグローバル関数名を使用するため、このドキュメントの例ではこの命名オプションも使用します。

メッセージ

投稿から始めましょう。 それらを送信するには、SendMessage（）関数を使用します。 この関数は非常に複雑なので、詳細に検討してください。

結果SendMessage（uint32_t message_id、const void * data、size_t data_length）

引数：

message_id-メッセージ識別子。
data-メッセージデータへのポインター。
data_length-メッセージデータの長さ。

使用例：

  const uint32_t APP5_EXPOSE_MESSAGE_ID = 503; ... if (broadcast) { char t = 0; SendMessage(APP5_EXPOSE_MESSAGE_ID, &t, sizeof(t)); } const uint32_t APP5_AIRPLANE_MESSAGE_ID = 504; ... bool AirplaneTask::SendAirplane() { Message msg(_x, _y, _deg, _visibility); return SendMessage(APP5_AIRPLANE_MESSAGE_ID, &msg, sizeof(msg)) == ResultOk; } 

関数の結果は、メッセージの送信ステータスを反映しています。 受信者が受信したかどうかにかかわらず、この機能はサイレントです。 それがなくなったかどうかだけが知られています。 確認するには、受信者が返信メッセージを送信する必要があります。

したがって、受信者側でメッセージを待機するには、次の関数が使用されます。

結果WaitUntilMessageReceived（SmMessageReceiveArgs＆args、uint32_t timeout_ms = INFINITE_TIMEOUT）

引数：

args-メッセージパラメータを持つオブジェクトへのリンク。

timeout_ms-ミリ秒単位のタイムアウト。 タイムアウト値がINFINITE_TIMEOUTの場合、タスクはタイムアウトによるロック解除の可能性なしでブロックされます（無限待機）。

メッセージオプションはクラス全体です。 オープンメンバーを簡単に検討してください。

uint32_t GetMessageId（）
受信したメッセージの識別子を返します：

size_t GetDataLength（）
受信したメッセージのデータサイズをバイト単位で返します。

void CopyDataTo（void *ターゲット）
メッセージデータを指定されたバッファにコピーします。 バッファのメモリは事前に割り当てる必要があります。 バッファーのサイズは、メッセージデータ（GetDataLengthメソッドを呼び出した結果）のサイズ以上でなければなりません。

したがって、前の例で送信されたメッセージの受信に役立つ例は次のようになります。

  void MessageReceiveTask::Execute() { Message msg; while (true) { SmMessageReceiveArgs args; Result res = WaitUntilMessageReceived(args); if (res == ResultOk) { uint32_t mid = args.GetMessageId(); switch (mid) { .... case APP5_EXPOSE_MESSAGE_ID: #ifdef BOARD_LEFT _gfx->ExposeAirplaneRed(); #else _gfx->ExposeAirplaneBlue(); #endif break; case APP5_AIRPLANE_MESSAGE_ID: { args.CopyDataTo(&msg); #ifdef BOARD_LEFT _gfx->UpdateAirplaneRed(msg.X, msg.Y, msg.Deg); _gfx->SetAirplaneRedVisibility(msg.Visibility); #else _gfx->UpdateAirplaneBlue(msg.X, msg.Y, msg.Deg); _gfx->SetAirplaneBlueVisibility(msg.Visibility); #endif } break; ... 

同期されたコンテキスト

コンテキストは、すべてのコントローラー間で同期する必要があるメモリの領域を指します。 同期中に追求される目標は任意です。 最も単純なケースは、1つのデバイスがホットスタンバイの完了した作業段階について他のデバイスに通知することです。 失敗した場合、残りのデバイスには作業をピックアップする方法に関する情報があります。 一緒に目標を達成するデバイスの場合、コンテキストを介した交換のメカニズムは、メッセージを介したものよりも便利かもしれません。 メッセージを生成、送信、受信、デコードする必要があります。 また、コンテキストのメモリを使用すると、通常のメモリと同じように作業できます。1つのデバイスのメモリが他のデバイスに複製されるように、同期を忘れないことが重要です。

システム内の同期されたコンテキストの数は任意です。 したがって、すべてを1つに収める必要はありません。 さまざまなニーズに合わせて、さまざまな同期コンテキストを作成できます。 メモリのサイズ、その中のデータ構造、および同期されたコンテキストの他のパラメーターは、アプリケーションプログラマの関心事です（それ自体、同期されたメモリの量が多いほど、同期が遅くなります。そのため、異なるニーズに対して異なる小さなコンテキストを使用する方が良いです）。

さらに、同期セッションの瞬間でさえ-アプリケーションプログラマによって選択されます。 RTOS MAXはサポート用のAPIを提供しますが、アプリケーションプログラマはその関数を呼び出す必要があります。 これは、データ交換のプロセスが比較的遅いという事実によるものです。 すべてがオペレーティングシステムに左右される場合、プロセッサコアが他のタスクを最大化する必要があるときに遅延が発生する可能性があります。 コンテキストを頻繁に自動同期すると、リソースが無駄になります。まれに、コントローラーが同期する前にデータが古くなる可能性があります。 これには、データがより重要な質問（たとえば、4人の異なるサブスクライバーがある場合）を追加します。その後、アプリケーションプログラマーのみが同期を開始できることが完全に明らかになります。 これを行うのが最適なタイミングを知っているのは彼であり、どのサブスクライバーが残りのデータを他のサブスクライバーに配布すべきかを知っています。 一方、OSはアプリケーションに透過性を提供します。

コンテキストには、独自の数値識別子があります（アプリケーションプログラマによって設定されます）。 すべてのアプリケーションは、1つまたは複数の同期されたコンテキストを持つことができます。 相互に作用するコントローラー内で識別子が一貫していることが重要です。
同期データの最も単純な例-清掃ロボットは、清掃されていない領域を把握するために、清掃した領域を定期的に地図上にマークします。また、お互いに干渉しないように、今どこに行くのかを知らせます。 1つの製品で作業しているレンチは、ねじ込みが完了した後、各ねじナットにマークを付けます。 タッチスクリーン付きのボードはクリックを記録し、残りのボードについてこの事実を記録しました。 さて、メモリを共有する必要がある他の多くのケースがありますが、これを毎秒数回（最大-毎秒数十回）行うことが許可されています。

したがって、コンテキストは図に示すように表すことができます。


図 5.コンテキスト

そして、その目的は次の図で表すことができます。


図 6.コンテキスト同期の本質

次に、コンテキストの同期に使用される関数を検討します。

結果GetContext（uint32_t context_id、void * data）;

コンテキストデータを指定されたメモリ領域にコピーします。メモリは事前に割り当てられている必要があります。 データ長が事前にわかっている場合（例えば、単純なフィールドを持つ構造）に適しています。

引数：

context_id-コンテキスト識別子。

data-コンテキストを保存するためのポインタメモリ領域。

その結果、最後の同期中に取得された、指定された識別子を持つコンテキストデータが返されます。 したがって、データはコンテキストのローカルコピーから取得されるため、この関数はすばやく動作します。 この関数には2番目のバリアントがあります。

結果GetContext（uint32_tcontext_id、void *＆data、size_t＆data_length）;

メモリを割り当て、データとコンテキストの長さをコピーします。 データ長が事前にわからない場合（たとえば、任意の長さの配列）に適しています。

引数：

context_id-コンテキスト識別子。

data-コンテキストを保存するためのポインタメモリ領域。

data_length-コンテキストを格納するメモリ領域のバイト単位のサイズ。

原則として、コンテキストが更新されるのを待つタスクを作成してから、その新しいデータをアプリケーションメモリにコピーできます。 これには次の関数が適しています。

結果WaitUntilContextUpdated（uint32_t＆context_id、uint32_t timeout_ms = INFINITE_TIMEOUT）

引数：

context_id-コンテキスト識別子。

timeout_ms-ミリ秒単位のタイムアウト。 タイムアウト値がINFINITE_TIMEOUTの場合、タスクはタイムアウトによるロック解除の可能性なしでブロックされます（無限待機）。

最後に、タスクがシステム全体（複数のコントローラーで構成される）でコンテキストを更新したい場合を考えます。

最初に、コンテキストをキャプチャする必要があります。 これを行うには、次の関数を使用します。

結果LockContext（uint32_t context_id）

引数：

context_id-コンテキスト識別子。

この機能にはコントローラー間の交換が必要であるため、時間がかかる可能性があります

コンテキストがキャプチャできた場合（同時にキャプチャしようとすると、1つだけが勝ち、残りはエラーコードを受け取ります）、次の関数を使用してコンテキストを記述できます。

結果SetContext（uint32_t context_id、const void * data、size_t data_length）

引数：

context_id-コンテキスト識別子。

data-コンテキストを保存するためのメモリ領域へのポインタ。

data_length-コンテキストを格納するメモリ領域のバイト単位のサイズ。

最後に、コンテキストを同期するには、関数を呼び出す必要があります。

結果UnlockContext（uint32_t context_id）

引数：

context_id-コンテキスト識別子。

コンテキストがシステム全体で同期するのは、呼び出し後です。

この機能にはコントローラー間の交換が必要であるため、時間がかかる可能性があります

作業例

OSに付属する同期コンテキストを使用した実際の例を考えてみましょう。 コードはファイルに含まれています... \ maksRTOS \ Source \ Applications \ CounterApp.cpp

この例では、複数のデバイスが1秒に1回カウンターをインクリメントします（このアプリケーションを画面のあるボードで実行すると、カウンター値が視覚的に表示されます）。 コントローラーのいずれかがオフになってからオンになった場合、カウンターの現在の内容を受け取り、すべてのユーザーと連携して動作します。 したがって、システムは、少なくとも1つのコントローラーがそのシステム内で動作するまでカウントを続けます。

この例を実行したアプリケーションプログラマは、「なぜですか？」という原則に基づいてコンテキスト識別子を選択しました。

 static const uint32_t m_context_id = 42; 

同期されるメモリは単純に見えます：

  uint32_t m_counter; 

関心のある主なアクションは、関数で発生します。

void CounterTask ::実行（）

最初に、コントローラーは見つけようとします：システムの最初ではありませんか？ これを行うために、彼はコンテキストを取得しようとします：

  Result result = GetContext(m_context_id, & m_counter); 

コントローラーが最初ではない場合、コンテキストが受信され、途中でシステムに存在するカウンター値が受信されます。

コントローラが最初の場合、コンテキストは受信されません。 この場合、次のように作成する必要があります（同じ場所で、カウンターは途中で消えます）。

  if ( result != ResultOk ) { m_counter = 0; result = LockContext(m_context_id); if ( result == ResultOk ) { SetContext(m_context_id, & m_counter, sizeof(m_counter)); UnlockContext(m_context_id); } } 

すべてが、今では確実にコンテキストが存在し、接続したばかりのシステムで発見されたか、作成されました。 無限ループに入ります：

  while (true) { 

そこで1秒間待機します。

  Delay(MAKS_TICK_RATE_HZ); 

そして、システム全体にカウンターを配布する権利をめぐってコンテストに勝とうとしています。

  result = LockContext(m_context_id); 

成功したら、配布します

  if ( result == ResultOk ) { GetContext(m_context_id, & m_counter); ++ m_counter; SetContext(m_context_id, & m_counter, sizeof(m_counter)); UnlockContext(m_context_id); } 

どうやら、コンテキストを配布しますが、受け取りません。 実際、この例では、新しく接続されたデバイスのみがコンテキストを取得します。 受信した場合、デバイスは自律的に動作します。 もちろん、絶えず連絡を取り合う方が良いですが、そのようなシステムの説明はより多くの紙を取ります、そしてあなたは心理学に反対することはありません、ほとんどの読者は単にあくびして次のセクションに進みます。 共有メモリの原理は、多かれ少なかれ明確になったと思います。