11

SPI を介して、一方の側のマイクロコントローラーと他方の側のマルチコア TI チップ上の ARM プロセッサとの間の効率的な通信プロトコルを設計しようとしています。

必要なプロトコルの要件:

1 - キューイングをサポートするマルチセッション。複数の送信/受信スレッドがあるため、この通信プロトコルを使用するアプリケーションは複数になり、これらのリクエストのキューイングを処理するプロトコルが必要です (送信が失敗した場合はバッファを保持し続けます)キューですが、キューのスケジューリングを管理するためのプロトコルが必要なだけです)。

2 - 基盤となるプロトコルとして SPI を介して動作します。

3 - 簡単なエラー チェック。

このスレッド: 「Simple serial point-to-point communication protocol」では、PPP が推奨されるオプションでしたが、PPP はジョブの一部しか実行しないようです。

また、PPP over Serial を特徴とする Light weight IP (LwIP) プロジェクト (これは SPI 経由で使用できると想定しています) を見つけたので、TCP/UDP などの上位層プロトコルを利用して残りの作業を行う可能性について考えました。必要なジョブ。幸いなことに、スターターウェア パッケージのイーサネット SW の一部として LwIP を含む TI を見つけました。これにより、少なくとも TI チップ側での移植が容易になると思います。

だから、私の質問は次のとおりです。

1 - この通信方式に LwIP を使用することは有効ですか? ポイント ツー ポイント (チップ レベル) 通信には必要のない IP ヘッダーが原因で、多くのオーバーヘッドが発生し、スループットが低下することはありませんか?

2 - LwIP に存在する TCP または類似のプロトコルは、送信要求のキューイングを処理しますか?プロトコルスタックによって管理されますか? もしそうなら、どのプロトコル層がそれを管理していますか?

3 - 上記の要件を満たす LwIP よりも効率的なプロトコル スタックですか?

アップデート 1: その他の考慮事項

1 - SPI が唯一の利用可能なオプションです。利用可能な GPIO と共に使用して、スレーブが送信するデータを持っていることをマスターに示します。

2 - 現在実装されている (非標準) プロトコルは、SPI を使用する DMA と、固定メッセージ フラグメント長の《STX_MsgID_length_payload_ETX》のメッセージ フォーマットを使用しますが、現在のスキームの主な欠点は、マスターがメッセージに対する応答を待機することです。 (フラグメントではない) 別のものを送信する前に、スループットを殺し、SPI の全二重の性質を利用しません。

3- この点の改善点は、フラグメントを受信するための一種のメールボックスを使用することでした。そのため、長いメッセージは優先度の高いメッセージによって中断され、単一のメッセージのフラグメントが順番に到着することはありませんが、問題は、この設計が原因であるということです。特に、コントローラー (マスター) 側でメールボックス アプローチを使用するための多くのバッファーに使用できるリソースがあまりないため、事態が複雑になります。つまり、単純なポイント ツー ポイント リンク用のプロトコル スタックを設計することによって、車輪を再発明しているように思えましたが、これは効率的ではない可能性があります。

4- 複数のセッションを確立し、メッセージのキューイング/スケジューリングを解決するために、SPI の上で通常使用できる上位レベルのプロトコルは何ですか?

更新 2:別の有用なスレッド「組み込みデバイス向けの優れたシリアル通信プロトコル/スタック?

更新 3: Modbus プロトコルを確認しました。アプリケーション レイヤーを指定してから、シリアル ライン通信用のデータ リンク レイヤーを直接指定しているようです。これは、ネットワーク指向のプロトコル レイヤーの不要なオーバーヘッドをスキップするように聞こえます。

意図された目的のために、これは LwIP よりも優れた選択肢になると思いますか? また、LwIP のように広く使用されているオープン ソースの実装がありますが、Modbus 用ですか?

4

2 に答える 2

1

マイクロコントローラーに完全な IP (lwip) スタックを本当に必要としない、またはその余地がないと思いますか? これはやり過ぎのように聞こえます。独自の単純なパケット構造をロールして、移動する必要があるデータ項目を移動してみませんか。spi が両側でどのようにサポートされているかによって、それを使用してデータのフレームを定義できる場合とできない場合があります。単純な開始パターンではない場合、長さと末尾のチェックサム、およびテール パターンでパケット境界を見つけるのに十分でしょう。ストリーム (シリアル/uart ソリューションと変わらない)。開始パターンで PPP ソリューションを使用することもできます。開始パターンがデータに現れるたびに、2 バイト パターンを使用するペイロードで終了パターンを考えます。私は今、すべての詳細を覚えていません。

フレームが何であれ、パケットの種類とハンドシェイクを追加します。または、データがアームするマイクロコントローラーになるだけの場合は、それを行う必要さえありません。

直接の質問に戻ります。はい、IP スタック (lwip など) は多くのオーバーヘッドをもたらすと思います。帯域幅と、さらに重要なのは、そのスタックをサポートするために必要なコードの量の両方が、両側で ROM/RAM を食いつぶします。最終的にこのデータを IP 形式 (組み込みシステムによってホストされる Web サイト) で表示する必要がある場合は、パスのどこかに IP スタックなどが必要です。

lwip がキューを管理するとは思えません。自分でやる必要があると思います。さまざまなキューが、単一の spi バスを処理する単一のドライバーと通信する必要がある場合があります (複数のチップ セレクトを備えた単一の spi バスがあると仮定します)。アームが複数のマイクロコントローラーと通信できるようにしており、データのパケットがこのコントローラーから少しずつ、そのコントローラーから少しずつに分割されている場合は、spi インターフェイスの使用方法にも依存します。さらに数バイトのデータを取得するずっと前に。それとも、次の gpio 割り込みに移動してデータを取得する前に、1 つのマイクロコントローラーから完全なフレームを移動する必要がありますか? 要するに、共有リソースの複数のユーザーがいる他の状況(rtos、本格的なオペレーティングシステムなど)と同じように、共有リソースを管理する必要があると思います。lwip についてはまったく覚えていませんが、本格的なバークレー ソケット アプリケーション インターフェイスを使用すると、ユーザーは、各アプリケーションが 1 つの TCP または UDP ポートのみを考慮し、ライブラリとドライバーがそれらのパケットを各アプリケーションに分離して管理する個別のアプリケーションを作成できます。 IP スタックのすべてのルール。

spi インターフェースを介してデータを移動する実験をまだ行っていない場合は、最初に簡単な実験から始めて、うまくいくかどうか、spi ごとに確実に実行できる転送のサイズを感じてください。トランザクションなど。あなたのソリューションは当然、これらの実験から外れるかもしれません。

于 2013-09-25T04:26:34.560 に答える