SPIまたはI2C:長いバスに使用するもの


36

私は、バスを介して互いに通信する複数のAVRを必要とするプロジェクトを考えています。それらは6フィートも離れているでしょう。

I2CとSPIの両方がバスを介して一連のマイクロを通信できるように思えますが、それがどれほど長くなるかについては何も話していません。誰かがこれらのプロトコルを数フィートの距離で接続しようとしましたか?


あるときケーブルを介してI2Cバスを走らせました。 後知恵では、代わりにCANまたはRS-485を使用する必要がありました(両端にマイクロコントローラーがありました)。
ニックアレキセフ

回答:


19

他の人が言ったように、SPIとI2Cは、プルアップ抵抗、クロック周波数などがあれば、長距離で使用できます。

主な代替手段(ノイズ耐性を向上させる)はRS485およびCANです。どちらもノイズの問題を最小限に抑えるために差動ラインを使用し、I2CやSPIよりもこの長さのデータ伝送に適しています。ただし、多くの(何か?)AVRにはCANペリフェラルが組み込まれているとは思わないため、CANの使用がはるかに簡単になります。

バスを選ぶ際に考慮すべき最も重要なことは、デバイス間の通信に使用するプロトコルにCRCまたは同等のものが含まれていることを確認して、メッセージが正しく受信されたかどうかを判断できるようにすることです(CANはこれをパケット)。これを考慮すると、破損したメッセージを再送信できるように、プロトコルの一部としてACK / NACKタイプの応答を持つことも役立ちます。


どちらかが動作するようです。ほとんどのAVRは追加のコンポーネントを追加せずにネイティブにサポートしているため、主にこれら2つの特定のプロトコルについて考えています。それ以外の場合は、RS485またはCANが適しています。
エデビル2009

スルーホールパッケージに限定されない場合、STにはコスト効率が高く強力なCANを備えたSTM32およびSTM8マイクロコントローラーがあり、NXPにはさまざまなLPC17xxマイクロコントローラーがあり、他にもいくつかあります。CANは、多くのマイクロコントローラーでますます一般的になっています(手頃な価格)。
-DrAl

1
実際、CANレシーバーが組み込まれたAVRがいくつかありますが、他のベンダーと同様、チップの限られたサブセットにしかありません。
-davr

1
MicrochipにはCANを備えたPICがいくつかあります。microchip.com/wwwproducts/Devices.aspx?dDocName=en010302。ただし、特にMicrochip社のC18 / C30ライブラリでは、これらはプログラムに少し「ファンキー」です。コードレビューで、実装の詳細のために読み取りが非常に困難なライブラリコードを確認しました。受信バッファーとして使用される送信バッファー、実際にはそれらが表すものとは反対のフラグ名です。確かに、マイクロコントローラー開発の初心者にはお勧めできません。
J.ポルファー

2
CANとRS-485は本当にリンゴとオレンジです。CANはビットレベルプロトコルと物理電気層(PHY)を定義します。RS-485は単なる物理層の仕様であり、プロトコルについては何も指定していません。RS-485 PHYの上に実際のプロトコルを見つけるか実装するのは完全にあなた次第です。CANは自動車や製造業で主に使用される高ノイズ環境向けに設計されました。そのプロトコルは、かなり複雑なメッセージパッシングシステムであり、非常に高いオーバーヘッド(実際のデータレートが低い)を持ちますが、データの整合性は高くなります。
マーク

10

数フィートでも問題はありません。可能であれば、撚り線を使用してください。SPIは、I2Cの信号は共有回線上にあるのに対して、SPI信号はすべて単方向であるため、I2Cよりもバッファリングがはるかに簡単です(必要な場合)。

AVRマイクロコントローラーはI2CおよびSPIスレーブモードとマスターモードを処理できますか?(両方が必要です)


2
ツイストワイヤ?? I2Cデータとクロックラインをねじらないでください!SPIの場合、これはおそらく問題ではありませんが、バランスの取れたペアでない限り、信号線をねじることはありません。その場合、ねじることは非常に良い考えです。
ウーターヴァンOoijen

絶対とは絶対言うな; ノイズの多いパワーエレクトロニクスへのマイナーな誘導結合(ツイストしないため)の代わりに、毎日データ+クロック間のマイナーな容量結合(ツイストのため)を取る
ジェイソンS

4
申し訳ありませんが、私は間違いなく同意しません。1状態では、ラインのインピーダンスはかなり高くなります。それが終わったのを見て、失敗したのを見た。最適なオプションは、I2Cラインの両側に低電流のグランドラインを配置することです。
ウーターヴァンOoijen

10

長距離のI2Cの場合、「I2Cバスリピーター」ソリューションを探してみてください。I2CまたはSPI通信の最大距離は、主にバス内の2つのノード間の距離ではなく、総バス距離を指していることに注意してください。

この種の問題については、RS485を調べてください。これは、差動ラインを介して通信するシリアルバスプロトコルであるため、ツイストワイヤを使用すると、ノイズの可能性が最小限に抑えられます。この方法で非常に長い距離に到達できます。欠点は、回路に余分なRS485エンコーダIC(MAX485など)が必要になることです。


RS485は間違いなくそのようなことをする良い方法です。
スコットマーフィー

RS485には、RS232とは多少異なる独立した2つの側面があることに注意してください。物理的な差動ロジックレベルとマルチマスターの側面です。これらを選択して選択することができます。RS485のマルチドロップ部分に入ることなく、ポイントツーポイントでUART(RS232)を備えたLVDSおよびRS485トランスレータを使用しました。
ジェイソンS

2
btw RS485はプロトコルではありません!物理層のみを定義します。とはいえ、間違いなくRS485経由でSPIを使用できます!!! 必要に応じて、SPIモードで通信を維持することは適切なソリューションになります(リモートADCなどに接続されている可能性があります)。SPI over RS485を使用する場合、トランシーバのスルーレートが提案されたSPIデータレートと互換性があることを確認する必要があります
-smashtastic

8

I2Cに対するSPIのまだ言及されていない利点の1つは、すべてのSPIワイヤが単方向であり、常にHighまたはLowに駆動されることです。これにより、I2Cを使用した場合よりもはるかに高速な通信が可能になり、ノイズの影響を受けにくくなり、シンプルなゲートをリピーターとして使用できます。もう1つの便利なオプションは、単純な非同期通信(各方向に1ワイヤー)です。非同期通信の唯一の欠点は、データを交換するために、通常は両側が安定したクロックで「起動」している必要があることです。

私自身のプロジェクトでは、わずかに変更された3線のSPIプロトコルを使用し、満足のいく結果が得られました。ディスプレイビットマップデータ(たまにデータが破損しても大した問題ではない)を10 mbpsで、その他のデータを2.5 mbpsで問題なく送信します。


これは非常に古い回答ですが、変更されたSPIプロトコルを送信している距離はどれくらいですか?(それが問題のポイントです...)
ダニエル・グリスコム

@DanielGriscom:通常、約3フィート、ひどく印象的なケーブルではなく、場合によってはそれ以上。
スーパーキャット

6

I2CとSPIはどちらも短距離(数インチ)の長距離用に設計されていますが、適切なケーブルとバス容量全体に注意を払うことで、長距離で使用できます。

SPIの経験はほとんどありませんが、プルアップ抵抗の適切なサイズを常に計算する必要があるため、I2Cはそれほど難しくありません。さらに、非常に使いやすい専用の安価なI2Cバッファーがあります。ただし、ネットワークには適切なサイズのプルアップ抵抗を使用する必要があります。

I2Cを使用して、8フィートの距離で2つのAVRをネットワーク接続し、プルアップ抵抗と高品質で十分にシールドされたツイストケーブルのみを使用しました。


多導体ケーブルを使用してI2Cに注意する必要がある場合、静電容量によりバスの速度が大幅に低下する可能性があります。
ジェイソンS

6

多くの人が示唆しているように、I2CとSPIは短距離に最適です。これらのインターフェイスを使用してソリューションを実装することも可能ですが、別の「より標準的な」ソリューション(イーサネット、RS485、CANなど)を探すことを強くお勧めします。-特に、ケーブルを使用してマイクロコントローラー間の6フィートの距離に到達することを計画している場合。


6

参考までに、ワイヤレスニンテンドーWiiリモコンとそのNunchuckコンパニオンとの間のインターフェイスは、長さ約3フィートのケーブルでI2Cを使用しています。全長を約6フィートまで延長する3フィート延長ケーブルもあります。セットアップとまったく同じではありません(2台のデバイスのみが接続されています)が、広く使用されている消費者製品のケーブルを介したI2Cの例です。


4

I2Cを介して通信するスター型ネットワークの約80のAVRベースのノードを含むプロジェクトに取り組みました。それは完全な混乱であり、最終的には機能しませんでした。すべてのノードの更新を取得するのに数秒かかり、1つの障害のある接続がネットワーク全体を切断しました。最後に、ノードを作成した人に話を聞いたところ、彼はこのようなプロジェクトでI2Cの使用をやめたと言いました。残念ながら、ここで具体的にI2Cが不適切だった理由はわかりません。


1
I2CはSPIよりもはるかに遅いです...衝突の場合にプロジェクトが調停を管理する方法にも関係しているかもしれません...
ジェイソンS

2

短い距離であれば簡単にできるはずです。できることは、それらの距離とケーブル接続がキャパシタンスとラインインピーダンスの観点から何を意味するかを把握し、それらを通過できる周波数の種類(立ち上がり/立ち下がり時間)を確認することです。特定のポイントを超えて、それらを伝送ラインとして扱うのが最善です。見栄えが悪い場合は、実際にEIA-232や422などの他のシリアルラインに切り替えることができます。これは、両端に余分なチップが含まれている可能性がありますが、伸びることがあります。本当に速く遠くまで行く必要がある場合は、さらに何かが必要になります(イーサネット、ラジオやレーザーは除外しないでください:)。


2

クロック速度を制御でき、高速データ転送が必要ない場合は、クロックを遅くするようにしてください。これにより、ノイズの影響を受けにくくなります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.