連続データストリームを構造単位に分割する

多くの場合、連続ストリームでデータブロックを転送する必要がある場合に状況が発生します。 この場合、データのブロックを別のブロックから分離する方法の問題が前面に出てきます。 問題は、データをバイナリで送信するかテキストで送信するかという背景になります。 これに加えて、小さな歪み（損失、ゴミ、相互作用するノードのエラー）を処理し続ける能力と、データ伝送チャネルの効率的な利用の必要性を追加します。 この場合、タスクは限られたリソースのシンプルなマイクロコントローラーで解決する必要があります。



このようなタスクは、たとえば、テレメトリ送信やリモート機器の制御で発生します。 一方には、通常、単純なマイクロコントローラーがあり、他方には、コンピューターがあります。 それらの間の通信は、古き良きRS232で実行できます。 たとえば、UARTマイクロコントローラの出力が802.11bに変換されると、さらに困難になる可能性がありますが、無線信号は無線マストに伝播し、イーサネットがサーバーに届きます。



このテーマで私の自転車が面白い場合は、猫にようこそ。



まず、要件を決定します。

1. チャンネルはいつでも作成できます。
2. コントローラーとコンピューターは、データ転送の途中を含め、いつでもチャネルに接続できます。
3. チャネルが歪んでいる場合、対応するデータブロックは破棄する必要があります。
4. 1つのチャネルに複数のデバイスを含めることができます。
5. データブロックには、任意のバイトシーケンスを含めることができ、任意の長さにすることができます。
6. プロトコルをサポートするために割り当てられたリソースは非常に限られています。

リモートでUDPに似た実装が判明しました。



3つの数字の「ストレス」を1つのブロックとして転送し、他の2つの数字を「温度」を別のブロックとして転送する例について、いくつかの一般的な方法を検討します。



多くの場合、テキスト形式で送信されるすべてのデータを変換し、改行でブロック（パケット）を分離することにより、この問題の解決策があります。



次のようになります。



V 1231、2400、-231

V 1333、2100、-232

T 36、-40

Sprintfが使用されます（buf、「V％d、％d」、...）。



伝送の問題：sprintfはかなりの量のスタックをかなり長い時間使用します。



受信の問題：コントローラーでは、「-232」文字セットをintに変換するには追加のリソースが必要です。 型制御なし、100,500エラーチェック条件。



プラスとして-人は送信されたパラメータを肉眼で見ることができます。



プロジェクトがこのプロトコルで開発を続けると、しばらくするとそれを維持することが不可能になり、人体分析の利用可能性さえ失われます。



10進数ではなく16進数を送信することで問題を部分的に解決することができます-これは処理を簡素化しますが、他の問題を保存しません。



制御を改善するために、送信されたデータをXMLでラップできます。

<?xml version="1.0" encoding="UTF-8"?> <voltages> <voltage num=”1”>1231</voltage> <voltage num=”1”> 2400</voltage> <voltage num=”1”> -231</voltage> </voltages>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、JSONでラップすることもできます。

 { “Voltages”: [1231, 2400, -231] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロトコルは文書化されます。 しかし同時に、コンパイル段階では型制御はまだありません。 また、追加で送信されるデータの量が過剰に大きくなります。 同時に、限られたリソースで数値とテキストを解析する問題が残ります。



ノードの1つが継続的に何かを送信する場合、2番目のノードを接続する瞬間は、送信されたデータの途中になる可能性があります。 ほとんどの場合、新しく起動したノードでパッケージの開始を確実に判断することはできないため、ラインフィードを待つか、運に頼る必要があります。 さらに、正確さのためのパケット制御はありません（たとえば、近い雷雨のため、1ビットが誤って送信されました）。 これらの欠点は、NMEAプロトコルと同様のアプローチを使用して解決できます。



$ GNVLT、1231,2400、-231 * 71



ここでは、パッケージの先頭は常に$で、パッケージの末尾はパッケージデータのアスタリスクとCRC（0x71）です。 これにより、不正なパッケージの問題は解決します（ここでの古典的なCRCは非常に単純です-XOR）が、パッケージの種類の文書化と制御の問題がまだあります。

テキストストリームを使用する場合、オーバーヘッドが多く、型の制御がわずかであり、文書化が困難であることがわかります。



バイナリデータ転送を検討してください。 バイトセットが送信されるため、構造を決定する必要があります。

 typedef struct { int16_t supplyIn; int16_t supplyOut; int16_t groundPotential; }PackVoltages; typedef struct { int8_t internal; int8_t outside; }PackTemperature;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

電圧には6バイト、温度には2バイトがあります。



これらの構造を1つに組み合わせ、さらにプロトコルを拡張するためにそこに別の5バイトを追加し、構造に送信データのタイプを入力できます。

 typedef struct{ char type; union { PackVoltages voltages; PackTemperature temperatures; }Data; char rezerv[5]; }FullPack;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

16バイトのパケット（アラインメントが明確でないため）を受け取りますが、12バイトではないように見えます（この例では、これは問題ではありませんが、アラインメントするときは注意が必要です）。 タイトバイトパッキングのコンパイラオプションを有効にできますが、別の問題が発生する可能性があります-一部のプロセッサ（ARMコア上）がアライメントされていないデータを読み取ることができず、初心者のJediがこのエラーを見つけるのはそれほど簡単ではありません。



さらに16バイトが常にチャネルに転送されます。 受信側は次の16バイトを待ち、次のパケットを処理します。 CRCがないことは簡単にわかります。 CRCを追加：

 typedef struct{ char type; union { PackVoltages voltages; PackTemperature temperatures; }Data; char rezerv[5]; char CRC; }FullPack;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パケットサイズは16バイトのままです。 データを送信するときは、パッケージのタイプを記録し、計算してCRCパッケージに入れてから、受信したパッケージを送信する必要があります。



このアプローチの利点は、パッケージを処理するときに、コンパイル時に型制御が表示されることです。 数値とテキストとの間の不要な変換はありません。 データの受信部分は常に同じサイズです-事前にメモリを割り当てると便利です。

多くの欠点があります。送信データの長さが大幅に異なる場合、小さな値から数十回までのデータ送信には不要なオーバーヘッドコストがあります。 この同期方法は、TCPチャネルを介したクライアントとサーバーの対話に適しています。途中で失われるものはなく、パケットの先頭は常に認識されています。 初期化よりも後のチャネルへの接続の状況では、最初の数バイトが到達していない状況が考えられます。 その後、受信したすべてのパケットはこのバイト数だけシフトされ、その中のデータは当然不正になります。 まあ、CRCがそれらをドロップすると、ノードとの接続はなくなります。 1/256の確率で、「壊れた」パケットを見逃す可能性があります。 パケットの「開始」の署名バイトを送信することでこの問題を解決することができますが、バイナリデータを送信すると、同じバイトがデータ自体にも発生する可能性があります。 したがって、パケットの開始を確実に判断できるとは限りません。 別の問題は、変数のアライメントです。 パケットヘッダーごとに1バイトが必要です。32ビットの数値はデータ自体に含まれていることが多く、0〜2バイトの定期的なデータシフトが発生します。 迷惑な迷惑は、異なるタイプのパケットを送信するときにCRCを「手動で」計算する必要があることです。



別のオプションは前のものと似ています。パケットの先頭でバイトを転送するオーバーヘッドを削減するために、実際の長さが送信されます。 このアプローチの問題は、パケットを事前に完全にカウント（つまり、メモリに収まる）してから送信する必要があることです。 これは、特に大きなパッケージの場合、マイクロコントローラーの限られたリソースでは困難なタスクになる可能性があります。 さらに、ライブラリがパッケージ全体を受信するまで、転送を開始できず、チャネルの帯域幅と遅延に悪影響を与える可能性があります。 その他の欠点と利点は、前のオプションと同様です。



そして、検討中の最後のメソッドは、私のライブラリでも使用されています。 歴史的な名前は、binプロトコルまたはBINプロトコルです。

バイナリデータを送信する場合、特別に割り当てられたバイトで区切ることができます。 同時に、このバイトがデータ内で見つかった場合、別のバイトシーケンスに置き換えます。 受信したら、逆の手順を実行します。 このメソッドは「バイトスタッフィング」と呼ばれます（ Flexzという名前に感謝します ）

CRCのカウントもパケットの送信を委任します。



異なる変換を機能させるには、3バイトを予約する必要があります。 それらがあまり一般的でないようにそれらを選択することが最善です。 バイト置換ルール：

<共有> = <共有> <共有>

<最終> = <共有> <オプション>

<オプション> = <オプション>



これは、データストリームで<Final>を宣言できないことを示しています。

パッケージは次の方法で作成できます。

<共有> Protocol_Data <最終>

信頼性を高めたい場合は、次の方法でパッケージを作成できます。

<Final> <Separator> Protocol_Data <Separator> <Final>



2番目の形式では、損傷した小さなパケットの拒否率が約15％増加しますが、オーバーヘッドは同じ10-15％増加するため、これ以上は考慮されません。



したがって、パケットを受信するとき、任意の時点で接続しても、「 共有」シンボルがパケットの受信を開始するのを待つだけで十分です。 そして、<Final>バイトを受信した後にのみ、パケットの正確性を確認し、処理のために送信する必要があります。



これで、「protocol_data」の構成を確認できます。



ヘッダー：1バイト-パケットタイプ、1バイトの宛先アドレス

データ：上記のルールに従って処理されたデータ自体

CRC：1バイト、上記のルールに従っても処理されます

つまり、任意のバイト数を送信でき、パケットの先頭と末尾のマーカーでラップされ、パケットタイプ、宛先アドレス、およびCRCが追加されます。



私たちの場合、これはデータ構造の定義のようになります。

 typedef struct { int16_t supplyIn; int16_t supplyOut; int16_t groundPotential; }PackVoltages; typedef struct { int8_t internal; int8_t outside; }PackTemperature;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、最初の構造が記号「V」で示され、2番目の構造が「T」で示されるという知識。 これらのパラメータの転送は、3つのパラメータを持つ関数によって実行されます。これは、パケットのタイプ、送信データの先頭のアドレス、および送信データの長さです。

BP_SendMyPack（ 'T'、＆packTemperature、sizeof（PackTemperature））;



そして、伝送チャネルには、次のようなシーケンスがあります。







小さなパッケージでは、かなり大きなオーバーヘッドが得られますが、パッケージのサイズが大きくなると見えなくなります。

灰色は送信されている実際の情報を示し、白は必要な最小限のサポート情報を示し、黄色はbinプロトコルのオーバーヘッドを示します。



このアプローチの利点は、オーバーヘッドがほとんどなく、任意の接続が問題にならず、適切なレベルのデータ抽象化があることです。同じ機能を使用して、異なるデバイス、プログラム、プロトコルで送受信できます。 コンパイル段階で適切な型制御を実現できます。 データ自体はプログラム内で正しい方法で調整できます。これにより、パケットを送信するときに余分なバイトが追加されることはありません。



短所：パケットのタイプとパケットのアドレスは特殊文字と同じにすることはできず、1から254の値をとることができます。CRCバイトは1つだけであるため、壊れたパケットが欠落する確率は1/256です。



異なるアーキテクチャ間でパラメータをバイナリ形式で渡す場合、 バイト順を考慮する必要があります 。 違いが生じた場合は、バイト順を反対に置き換える変換関数を使用する必要があります。



プロトコルの実例として、QTの小さなプログラムが添付されています。 起動時に、プログラムはTCPソケットを開き、このソケットに接続するためのパラメーターを使用して自分自身を再起動します。 つまり、プログラムの2つのほぼ同一のインスタンスが作成され、TCPソケットを介して相互接続されます。 必要に応じて、必要なキーから開始して、プログラムのサーバーまたはクライアントを個別に実行できます。



利用可能なキー：

-dedicated-サーバーを作成し、接続パラメーターをコンソールに表示します。

-child-指定された属性に接続します：

-A：11.22.33.44 -IP接続アドレス（デフォルトlocalhost）

-P：12345-接続ポート

キーなし-サーバーとクライアントを起動し、それらを接続します。

プログラム-バイナリプロトコルを介してユーザーアクションをソケットに変換し、リターンチャネルをリッスンし、受信したデータに基づいてアクションを実行します。

プログラムでは、黒い背景上のマウスボタンは、ボタンが放されるまで拡大円を描きます。 上の虹の帯をクリックすると、現在の色が変わります。 2台の異なるコンピューターから赤ちゃんとペアを描くのはとても楽しいです:)



バイナリプロトコルを使用するための説明。

MainWindowクラスでは、すべてのプロトコルとTCP接続の相互作用が収集されます（TCPの代わりに、他のものを使用できます）。



コンストラクターMainWindow :: MainWindowは、プライベート関数initBinProtocol（）を呼び出します。 プロトコルを初期化します。 同じ場所で、「発行バイト」globalSendCharToExternal（）の関数のアドレスがプロトコルに渡されます。 次に、TCPソケット内の文字のシグナル到着のハンドラーがReadFromParent（）にインストールされ、最終的に文字ごとにすべての受信バイトがプロトコルハンドラーに転送されます。



TCPを接続した後、別のReadFromChild（）ハンドラーが接続されたセッションでハングします。これは同様に、受信したすべてのバイトをプロトコルハンドラーに転送します。



PackTypes.hファイルには、すべてのタイプの送信パケットが含まれています。 これは実際にはプロトコルの説明です。 タイプTPackAllTypesは、コンピューターでの処理を容易にするために導入されたもので、マイクロコントローラーでこのタイプを使用する必要はありません。



PaintBoxクラスには、プロトコル自体が含まれています。 プログラムの他のインスタンスからのパッケージは、タイマーによって50ミリ秒ごとにチェックされます。 必要に応じて、パケット全体の最後のバイトを受信する処理を実行できます。



イベントは、マウスボタンが押されて離されたとき、およびBP_SendMyPack（）関数を介して「クリア」ボタンが押されたときにプロトコルに送信されます。 最初に、バイナリパラメータ値を持つ構造が入力され、次に送信されます。 クリーニングコマンドを送信するには-データは不要で、送信されるのはコマンドバイトのみです。



PaintBox :: timerCheckPacks（）関数では、プロトコルバッファー内の既存のコマンド（ BP_IsPackReceived（） ）とその実行に対して定期的なチェックが実行されます。



Types.hファイルには、異なるプラットフォーム用の異なるコンパイラーによるクロスコンパイルのための同様の基本タイプの定義が含まれています。場合によっては、編集する必要があります。



一般に、コードは文書化されているため、把握するのは難しくありません。



ライブラリを使用したgithubへのリンク：

• git：git@github.com：Elvish / microkern.git
• http： https : //github.com/Elvish/microkern

PS。 そして、どのようにストリームを断片に分割しますか？ 質問があれば、答えようとします。 トピックに興味がある場合は、次の記事で、最も単純なコントローラー（ほとんどすべての小さなデバイスのデバッグに不可欠なもの）の自動追加機能を備えた簡易シェルを発行できます。



UPD。

Flexzの別の粉砕方法：

たとえば、 Modbus-RTUプロトコルで使用される方法。 パケットは「無音」の間隔で区切られ、ラインはいくつかの文字を送信するのに必要な時間、非アクティブ状態で保存されます。 この場合、バイトスタッフィングを解析するために各バイトを処理する必要はありません。もちろん、DMAレシーバーが使用可能であれば、それを使用できます。



著者から：私の意見では、時間の分割は、負荷の軽い回線または非常に正確な時間で可能です。 物理データ転送の監視が困難な状況（たとえば、WiFi経由の中継）。 パッケージは互いに組み合わせるか、任意に分割できます。 一部のUSB-RS232アダプターでさえこれを引き起こします。8バイトのパケットを結合するため、すべてのハードウェアがアダプターを介して機能するわけではありません。



パケットの先頭と末尾に2つの異なるバイトが存在することは、プロトコルの安定性が向上し、チャネルが大幅に失われることに関連しています。 当初、プロトコルは、可視性が非常に低いモバイル機器で古代の無線モデムによって送信が行われたときに開発されました。 1バイトでは、プロトコルはしばしば、1つのパケットの始まり（送信失敗）と別のパケットの終わりを受信するときにミスを犯しました。