SPI oder I2C: was für einen längeren Bus zu verwenden ist

Ich erwäge ein Projekt, bei dem mehrere AVRs über einen Bus miteinander sprechen müssten. Sie würden bis zu 6 Fuß voneinander entfernt sein.

Es scheint, als könnten sowohl I2C als auch SPI eine Reihe von Mikros über einen Bus kommunizieren lassen, aber ich habe nichts darüber gesehen, wie lange das dauern würde. Hat jemand versucht, diese Protokolle über Entfernungen von mehreren Metern zu verbinden?

Ich habe den I2C-Bus einmal über ein Kabel laufen lassen. Im Nachhinein hätte ich stattdessen CAN oder RS-485 verwenden sollen (hatte Mikrocontroller an beiden Enden).

Antworten (10)

Wie andere gesagt haben, können SPI und I2C über große Entfernungen verwendet werden, solange die Pull-up-Widerstände, Taktfrequenzen usw.

Die Hauptalternativen (die eine bessere Störfestigkeit bieten) sind RS485 und CAN . Beide verwenden differentielle Leitungen, um Rauschprobleme zu minimieren, und sind für diese Länge der Datenübertragung besser geeignet als I2C oder SPI. Ich glaube jedoch nicht, dass viele (keine?) AVRs mit eingebauten CAN-Peripheriegeräten ausgestattet sind, die die CAN-Nutzung viel einfacher machen.

Ich würde sagen, dass das Wichtigste, was Sie bei der Auswahl eines Busses beachten sollten, darin besteht, sicherzustellen, dass das Protokoll, das Sie für die Kommunikation zwischen Geräten verwenden, einen CRC oder etwas Ähnliches enthält, damit Sie feststellen können, ob eine Nachricht korrekt empfangen wurde (CAN hat dies als Teil von das Paket). In Anbetracht dessen ist es auch nützlich, eine Antwort vom Typ ACK/NACK als Teil des Protokolls zu haben, damit eine beschädigte Nachricht erneut übertragen werden kann.

Es hört sich so an, als würde beides funktionieren. Ich denke hauptsächlich an diese beiden speziellen Protokolle, weil die meisten AVRs sie nativ unterstützen, ohne zusätzliche Komponenten hinzuzufügen. Ansonsten wäre RS485 oder CAN eine gute Wahl.
Wenn Sie nicht auf Through-Hole-Gehäuse beschränkt sind, dann hat ST seine kostengünstigen und leistungsstarken STM32- und STM8-Mikrocontroller mit CAN, NXP hat eine Reihe von LPC17xx-Mikrocontrollern und es gibt noch einige andere da draußen. CAN wird auf vielen Mikrocontrollern immer häufiger (und erschwinglicher).
Es gibt tatsächlich einige AVRs mit eingebauten CAN-Empfängern, aber genau wie bei den anderen Anbietern ist dies nur in einer begrenzten Teilmenge ihrer Chips der Fall.
Microchip hat einige PICs mit CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Ich gebe jedoch zu, dass sie ein bisschen "funky" zu programmieren sind, besonders in den C18/C30-Bibliotheken von Microchip. Bei der Codeüberprüfung haben wir Bibliothekscode beobachtet, der aufgrund von Besonderheiten der Implementierung sehr schwer zu lesen war – ein Sendepuffer, der als Empfangspuffer verwendet wird, Flag-Namen, die eigentlich das Gegenteil von dem sind, was sie darstellen. Sicherlich nichts, was ich jemandem empfehlen würde, der neu in der Mikrocontroller-Entwicklung ist.
CAN und RS-485 sind wirklich Äpfel und Birnen. CAN definiert das Bit-Level-Protokoll sowie die physikalische elektrische Schicht (PHY). RS-485 ist nur eine Spezifikation der physikalischen Schicht, sie spezifiziert nichts über das Protokoll. Es liegt ganz bei Ihnen, ein aktuelles Protokoll zusätzlich zum RS-485-PHY zu finden oder zu implementieren. CAN wurde für Umgebungen mit hohem Rauschen entwickelt und wird hauptsächlich in der Automobil- und Fertigungsindustrie eingesetzt. Sein Protokoll ist ein ziemlich komplexes Nachrichtenübermittlungssystem und hat einen sehr hohen Overhead (niedrige tatsächliche Datenrate), aber eine hohe Datenintegrität.
I2C kann nicht über beliebige Längen verwendet werden, wie Ihre erste Zeile andeutet. Die maximale Länge ist eine Funktion der Leitungskapazität, des minimalen Pull-up-Werts und der minimalen Anstiegsgeschwindigkeit.

Mehrere Meter sollten kein Problem sein, verwenden Sie einfach verdrillte Drähte, wenn Sie können. SPI ist viel einfacher zu puffern (falls erforderlich) als I2C, da SPI-Signale alle unidirektional sind, während die Signale von I2C auf gemeinsam genutzten Leitungen liegen.

Können die AVR-Mikrocontroller I2C- und SPI-Slave-Modi sowie Master-Modi verarbeiten? (Du brauchst beides)

verdrehte kabel?? Verdrillen Sie NIEMALS die I2C Daten- und Taktleitungen! Mit SPI ist dies wahrscheinlich weniger problematisch, aber ich würde niemals Signalleitungen verdrillen, es sei denn, es handelt sich um ein symmetrisches Paar. In diesem Fall ist das Verdrillen eine sehr gute Idee.
Sag niemals nie; Ich würde jederzeit eine geringfügige kapazitive Kopplung (wegen des Verdrehens) zwischen Daten + Takt anstelle einer geringfügigen induktiven Kopplung mit verrauschter Leistungselektronik (wegen des Nichtverdrehens) nehmen.
Entschuldigung, ich bin definitiv anderer Meinung. Im 1-Zustand sind die Leitungen ziemlich hochohmig. Gesehen, es getan, gesehen, wie es gescheitert ist. Die beste Option ist, Erdungsleitungen mit niedrigem Strom zwischen oder noch besser auf beiden Seiten der I2C-Leitungen zu haben.
@JasonS - Damit ein verdrilltes Paar funktioniert, muss das gesendete Signal im Rückleiter gespiegelt werden, damit sich die Magnetfelder gegenseitig aufheben und das Paar nicht induktiv wird. Und das hebt auch die EMI auf, die Tatsache, dass es sich um ein Differenzpaar handelt, das sich wahrscheinlich gut als direkt mit einem Operationsverstärker verbunden darstellt, um das Signal zu empfangen. Ich stimme Wouter van Ooijen zu, dass Sie die I2C-Daten- und Taktleitungen NIEMALS verdrehen sollten!
nicht sicher, ob ich zustimme; Ich würde das gesamte Set (SCL + SDA + GND) zusammendrehen.

Für I2C über große Entfernungen möchten Sie vielleicht nach einigen "I2C-Bus-Repeater" -Lösungen suchen. Denken Sie daran, dass sich die maximale Entfernung, die Sie möglicherweise für die I2C- oder SPI-Kommunikation finden, hauptsächlich auf die Gesamtbusentfernung und nicht auf die Entfernung zwischen zwei Knoten in einem Bus bezieht.

Vielleicht möchten Sie RS485 für diese Art von Problemen untersuchen. Es handelt sich um ein serielles Busprotokoll, das über differentielle Leitungen kommuniziert, sodass bei Verwendung von verdrillten Drähten die Wahrscheinlichkeit von Rauschen minimiert wird. Auf diese Weise können sehr große Entfernungen erreicht werden. Der Nachteil wäre, dass Sie einen zusätzlichen RS485-Encoder-IC (wie einen MAX485, nicht sehr teuer) in Ihrer Schaltung benötigen würden.

RS485 ist definitiv ein guter Weg, um so etwas zu erreichen.
Denken Sie daran, dass RS485 zwei Aspekte hat, die sich von RS232 unterscheiden und etwas unabhängig sind: die physikalischen differentiellen Logikpegel und der Multimaster-Aspekt. Sie können diese auswählen und auswählen, wir haben sowohl LVDS- als auch RS485-Übersetzer mit UART (RS232) für Punkt-zu-Punkt verwendet, ohne in die Multidrop-Teile von RS485 einzusteigen.
btw RS485 ist kein Protokoll! es definiert nur die physikalische Schicht. Allerdings können Sie SPI definitiv über RS485 verwenden !!! Es wäre eine nette Lösung, die Kommunikation bei Bedarf im SPI-Modus zu halten (ich gehe davon aus, dass dies mit einem entfernten ADC oder ähnlichem verbunden sein könnte). Wenn Sie SPI über RS485 verwenden, müssen Sie überprüfen, ob die Anstiegsraten des Transceivers mit den vorgeschlagenen SPI-Datenraten kompatibel sind

Nur zu Ihrer Information, die Schnittstelle zwischen der drahtlosen Nintendo Wii-Fernbedienung und ihrem Nunchuck-Begleiter verwendet I2C über ein etwa 3 Fuß langes Kabel. Es gibt auch 3-Fuß-Verlängerungskabel, die die Gesamtlänge auf etwa 6 Fuß verlängern. Nicht genau das gleiche wie Ihr Setup (nur zwei Geräte miteinander verbunden), aber es ist ein Beispiel für I2C über ein Kabel in einem weit verbreiteten Verbraucherprodukt.

Ein noch nicht erwähnter Vorteil von SPI gegenüber I2C ist, dass alle SPI-Drähte unidirektional sind und immer hoch oder niedrig angesteuert werden. Dies ermöglicht eine viel schnellere Kommunikation als mit I2C, reduziert die Störanfälligkeit und ermöglicht die Verwendung einfacher Gates als Repeater. Eine weitere nützliche Option ist eine einfache asynchrone Kommunikation (ein Draht in jede Richtung). Der einzige Nachteil, den ich bei der asynchronen Kommunikation sehen kann, ist, dass im Allgemeinen beide Seiten "wach" sein müssen, mit einer stabilen Uhr, um Daten auszutauschen.

Für ein eigenes Projekt habe ich ein leicht modifiziertes 3-Draht-SPI-Protokoll verwendet und fand die Ergebnisse zufriedenstellend. Ich sende Display-Bitmap-Daten (bei denen gelegentliche Datenbeschädigung keine große Sache wäre) mit 10 MBit/s und andere Daten problemlos mit 2,5 MBit/s.

Dies ist eine sehr alte Antwort, aber würden Sie sagen, über welche Entfernung Sie Ihr modifiziertes SPI-Protokoll gesendet haben? (Darum geht es bei der Frage...)
@DanielGriscom: Typischerweise etwa 3 Fuß, über nicht besonders beeindruckende Verkabelung, aber manchmal länger.

Während sowohl I2C als auch SPI für Kurzstreckenstrecken (wenige Zoll) ausgelegt sind, können beide bei längeren Strecken mit geeigneten Kabeln und unter Berücksichtigung der Gesamtbuskapazität verwendet werden.

Obwohl ich wenig Erfahrung mit SPI habe, ist I2C nicht besonders schwierig, da Sie immer die richtige Größe für Ihren Pull-up-Widerstand berechnen müssen. Darüber hinaus gibt es dedizierte und kostengünstige I2C-Puffer, die recht einfach zu verwenden sind. Sie müssen jedoch immer noch einen richtig dimensionierten Pull-up-Widerstand für Ihr Netzwerk verwenden.

Ich habe I2C verwendet, um zwei AVRs in einer Entfernung von 8 Fuß zu vernetzen, wobei ich nur Pull-up-Widerstände und hochwertige, gut abgeschirmte, verdrillte Kabel verwendet habe.

bei mehradrigen Kabeln muss man bei I2C aufpassen, die Kapazität kann den Bus stark verlangsamen.

Wie viele vorgeschlagen haben, werden I2C und SPI am besten für kurze Entfernungen verwendet. Auch wenn es möglich ist, eine Lösung mit diesen Schnittstellen zu implementieren, würde ich Ihnen dringend empfehlen, sich nach einer anderen, "standardmäßigeren" Lösung umzusehen (z. B. Ethernet, RS485, CAN usw.). -- Vor allem, wenn Sie vorhaben, Kabel zu verwenden, um die Entfernung von 6 Fuß zwischen Mikrocontrollern zu erreichen.

Ich habe an einem Projekt mit etwa 80 AVR-basierten Knoten in einem Sternnetzwerk gearbeitet, das über I2C kommuniziert. Es war ein totales Durcheinander und hat am Ende nicht funktioniert. Das Abrufen von Updates für alle Knoten dauerte Sekunden, und eine fehlerhafte Verbindung würde das gesamte Netzwerk lahmlegen. Als ich zuletzt mit dem Typen gesprochen habe, der die Knoten erstellt hat, sagte er, er habe aufgehört, I2C für Projekte wie dieses zu verwenden. Leider weiß ich nicht, warum speziell I2C hier unzureichend war.

I2C ist viel langsamer als SPI ... es könnte auch daran gelegen haben, wie Ihr Projekt die Schlichtung bei Kollisionen verwaltet hat ... oder die Kapazität war bei all diesen Knoten hoch genug, dass Sie nur eine langsame Taktrate verwenden mussten.

Bei so kurzen Distanzen sollte es einfach sein. Was Sie tun könnten, ist herauszufinden, was diese Entfernungen und Ihre Verkabelung in Bezug auf Kapazität und Leitungsimpedanz bedeuten, und zu sehen, welche Art von Frequenzen (Anstiegs- / Abfallzeiten) Sie durch sie erreichen können. Ab einem bestimmten Punkt ist es am besten, sie als Übertragungsleitungen zu behandeln. Wenn es schlecht aussieht, könnten Sie tatsächlich zu einer anderen seriellen Leitung wie EIA-232 oder 422 wechseln. Das könnte einen zusätzlichen Chip an beiden Enden bedeuten, wird aber weit reichen. Wenn Sie wirklich schnell und weit gehen müssen, brauchen Sie etwas mehr (Ethernet, zählen Sie nicht Radio oder Laser :).

Wenn Sie die Taktrate steuern können und keine Hochgeschwindigkeits-Datenübertragung benötigen, sollten Sie versuchen, die Taktrate zu verlangsamen. Dadurch wird es weniger anfällig für Geräusche.