Raspberry Pi Zero-Verbindung zum Sensor (mit I²C- oder SPI-Bus-Schnittstelle) über eine große Entfernung

ZUSAMMENFASSUNG:

Hier ist, was funktioniert:

Raspberry Pi (I²C) <-> 1 m Kabel <-> Sensor (I²C)

Folgendes versuche ich zu tun (funktioniert nicht, daher Frage):

Raspberry Pi (I²C) <-> 30 m Kabel <-> Sensor (I²C)

Die zu lösende "Gleichung" lautet also:

Raspberry Pi (I²C, SPI und andere) <-> X <-> 30 m Kabel <-> Y <-> Sensor (I²C/SPI)

Löse nach X und Y auf

DETAIL:

Ich arbeite mit einer Reihe von Sensoren, die in einem Sternnetzwerk / einer Sterntopologie konfiguriert sind.

Geben Sie hier die Bildbeschreibung ein

Als zentraler „Hub“ dient ein Raspberry Pi Zero, an dem alle Sensordaten gesammelt und verarbeitet werden. Alle Sensoren sind gleich und verwenden ein I²C-Protokoll (sie bieten auch eine SPI-Bus-Schnittstelle). Abgesehen davon habe ich derzeit einen I²C-Multiplexer an den Raspberry Pi Zero angeschlossen, um mehrere Geräte zu aktivieren, die mit derselben I²C-Hardwareadresse konfiguriert sind. Alle Sensoren sind über ein abgeschirmtes 26/4-Kabel mit dem Raspberry Pi Zero verbunden. Aktuell funktioniert alles wie vorgesehen.

Nachdem ich den Machbarkeitsnachweis erbracht habe, möchte ich nun die Reichweite des Sternnetzwerks/der Sterntopologie um 20–30 m auf jeder Sensor-Hub-Verbindung erweitern. Ich dachte, ich könnte einfach längere Kabel verwenden, aber anscheinend begrenzt das I²C-Protokoll die Länge der Kabelverlängerung. Ich habe verschiedene Tricks / Lösungen gelesen , wie man die Länge verlängern kann, z. B. die Frequenz verringern, Widerstände ändern usw.

Ich werde ehrlich sein; Ich bin kein Elektroingenieur, daher scheinen einige dieser Dinge etwas fortgeschrittener zu sein, und ich habe nicht wirklich das Wissen oder die Werkzeuge, um die Wirksamkeit dieser Art von Auseinandersetzungen zu beurteilen.

Wie auch immer, ich habe etwas gegraben und verschiedene Chips gefunden, die ich möglicherweise eher als "Plug-and-Play" -Lösung implementieren kann. Abgesehen davon stammt ein Großteil des Materials, das ich gelesen habe, von vor Jahren, und ich weiß nicht, ob diese Lösungen noch brauchbar sind. Hier sind die Chips, die ich gefunden habe

  • P82B96, der anscheinend einen Nachfolger hat: PCA9600?
  • P82B715

Beim Vergleich der beiden habe ich gelesen, dass der erste Punkt vielseitiger ist. Ich habe auch gelesen, dass der zweite Artikel älter ist und viel Strom benötigt , was Remote-Bereitstellungen (batteriebetrieben) weniger praktisch macht. Ich bin kürzlich auf eine andere Lösung gestoßen, bei der Sie einen I²C-zu-1-Draht-Konverter verwenden , da das 1-Draht-Protokoll nicht so empfindlich auf eine Zunahme der Drahtlänge reagiert

  • DS28E17 (und möglicherweise DS2484 am Hub hinzufügen)

Dies scheint eine mögliche Lösung zu sein, aber ich habe nicht viel darüber gehört, dass es von anderen verwendet wird. Die einzige Informationsquelle, die ich bekam, war die Firmenwebseite und Videos. Wenn ich das Datenblatt richtig gelesen habe, benötigt die Lösung auch nicht viel Strom. Ich frage mich, ob andere kaufen, was sie verkaufen, und ob es funktioniert?

Wie auch immer, ich bin kein Elektroingenieur, also könnte ich wirklich einen Rat gebrauchen. Es scheint, als ob das I²C-Protokoll das ist, was viele Sensoren verwenden (zumindest der DIY-Embedded-Markt), also nehme ich an, dass ich nicht der Einzige bin, der mit dem Problem der Erweiterung der I²C-Kommunikation konfrontiert ist .

Hier sind meine Lösungsanforderungen:

  • Verlängern Sie jeden Sensor um 20-30 m von der zentralen Nabe
  • muss eine kabelgebundene Verbindung sein
  • geringer Stromverbrauch (ich betreibe das Netzwerk im Akkubetrieb)

BEARBEITEN: Ich habe am Wochenende etwas mehr gegraben und bin auf diesen Chipsatz (MCP25 *) gestoßen, der wie eine CAN-zu-SPI-Schnittstelle klingt. DAS WIRD NICHT FUNKTIONIEREN ... SIEHE @Maples Kommentare unten.Ich sage sicherlich nicht, dass dies der einzige Chipsatz ist, der diese Konvertierung anbietet, es ist nur der erste, auf den ich gestoßen bin. Die Sensoren, die ich verwende, haben eine SPI-Bus-Schnittstelle, also denke ich, dass ich vielleicht einen dieser Chips direkt an jeden Sensor anschließen kann? Ich habe in meiner Sterntopologie nur 5 Sensorknoten mit dem Raspberry Pi verbunden, daher glaube ich, dass ich mich innerhalb der Beschränkungen für die Anzahl der Knoten befinde, die der CAN-Bus unterstützen kann. Die Frage wäre dann, wie man den Rest des Busses konfiguriert. Würde ich einfach ein Ende eines Cat-5-Kabels an einen der CAN-to-SPI-Chips anschließen? Das Kabel würde dann 20-30 m zum Raspberry Pi verlaufen. Könnte ich dann einen weiteren Chip am Raspberry Pi hinzufügen, um die Konvertierung zu "invertieren" und mit dem Raspberry Pi zu kommunizieren? Gibt es eine Möglichkeit, alle fünf Knoten mit derselben Schnittstelle/einem Chip zu verbinden? ich nicht Ich glaube nicht, dass der Raspberry Pi eine native CAN-Bus-Unterstützung hat, aber offensichtlich SPI (ich denke, Sie können nur zwei Geräte anschließen?). Wenn diese Chips auf den Sensorknoten hinzugefügt werden könnten, was wäre erforderlich, um den Raspberry Pi anzuschließen?

EDIT_2: Nachdem ich weitere Erkenntnisse aus dem Feedback aller gesammelt hatte (danke), beschloss ich, weiter zu graben. Kein Wunder, dass ich auf eine weitere mögliche Lösung gestoßen bin! Ich habe die Kommentare zu einem der Links gelesen, auf die ich oben hingewiesen habe , und jemand hat einen PCA9615-Chip erwähnt . Eine schnelle Google-Suche auf diesem Chip führt zu "Differential-I²C". Aus Laiensicht klingt das nach einer Lösung, bei der ich meine Software nicht ändern müsste. Abgesehen davon kenne ich die Vor- und Nachteile nicht vollständig oder ob es meine drei aufgeführten Anforderungen erfüllt. Ich werde das Datenblatt weiter lesen, aber wenn jemand Feedback zu dieser Lösung hat, bin ich ganz Ohr!

20-30 m sind für den I2C-Bus etwas lang, es sei denn, Sie betreiben ihn mit einer Taktrate von 1 kHz. Und haben eine zentrale Stromversorgung vom selben Root-Hub. Und verwenden Sie abgeschirmte Kabel. Es ist eine große Strecke.
Die Signalleistung muss mit der Leistung des nahen Rauschens und dem Kopplungsimpedanzverhältnis zum Bus verglichen werden.
@NickAlexeev Ja, ich glaube, ich bin auf diese Kreuzung gestoßen und versuche zu vermeiden, den Fehler zu machen, i2c übermäßig zu verwenden
@ThatsRightJack Re BEARBEITEN. Es gibt keine "spi-to-can"-Schnittstelle. Das sind CAN- Controller mit SPI-Schnittstelle. Ihre MCU sendet SPI-Befehle an die Steuerung, wodurch sie Daten über CAN sendet / empfängt. Grundsätzlich ist der CAN-Controller das Slave-Gerät, genau wie Ihr SPI-Sensor. Sie können nicht zwei Sensoren miteinander verbinden, obwohl beide über SPI-Schnittstellen verfügen.
@Maple Wollen Sie damit sagen, dass der Raspberry Pi (SPI) <-> CAN-Controller <-> 30 m Kabel <-> CAN-Controller <-> Sensor (SPI) zu viele "Slaves" miteinander verbunden sind?
Ich sage, dass "CAN-Controller <-> Sensor (SPI)" keinen Sinn ergibt. Der CAN-Controller ist genau wie der Sensor selbst. Sie können nicht zwei Sensoren miteinander verbinden. Sie können das SPI-Gerät nur an die MCU anschließen, da es von Ihrem Code gesteuert werden muss. Sensor hat keinen Code, er kann den CAN-Controller nicht steuern.
Auch (obwohl es in diesem Fall keine Rolle spielt) können Sie den CAN-Controller nicht direkt an das Kabel anschließen. Sie benötigen CAN-Transceiver-Chips zwischen Controllern und Kabel. Die, die ich Ihnen in meiner Antwort vorgeschlagen habe.
Re PCA9615-Chip. Es ist nur ein weiterer Single-Ended-to-Differential-Transceiver. Und nicht sehr gut, IMO. Die Höchstgeschwindigkeit fällt schnell über 3 m Kabellänge und der Stromverbrauch ist ziemlich hoch. Übrigens erforderten die meisten der Ihnen bisher vorgeschlagenen Lösungen keine Softwareänderungen.

Antworten (4)

Die Onewire-Lösung mit dem DS28E17 ist diejenige, die meistens out of the box funktioniert. Sie können sogar den Bitbanging-Host (z. B. auf GPIO4) verwenden und kommen fast ohne zusätzliche Hardware aus. Jeder DS28E17 auf dem Bus erscheint automatisch als I²C-Hostadapter, es sind keine Softwareänderungen erforderlich. Nachteile:

  • Der Onewire muss ein Bus sein, kein Star. Wenn Sie ein Sternlayout hatten, verwenden Sie Lobes, um daraus einen physischen Bus zu machen. Oder nutzen Sie mehrere Onewire-Busse, der DS2482-800 bietet acht.
  • Es ist langsam, nur etwa 15 kBaud mit viel Overhead. Sie können es nicht für Sensoren mit hohem Durchsatz verwenden.

Vergessen Sie den DS2484 hinter einer DS28E17- Idee. Das gleicht einfach den Overhead aus, so dass das Senden einiger Bytes ungefähr eine Sekunde dauert. (DS28E17 hinter einem DS2484 oder DS2482-800 ist im Gegensatz dazu die beabsichtigte Verwendung und vermeidet Bitbanging.)

Der Grund dafür, dass der Chip noch nicht viel von anderen Leuten verwendet wird, ist, dass er erst 2016 herauskam und der Linux-Treiber erst seit Kernel 4.15 verfügbar ist.

(Und eine Warnung: Der DS28E17 ist ein reines 3,3-V-Gerät.)

Ich denke, "Sie können sogar den Bitbanging-Host verwenden" sollte durch "Sie müssen Bitbanging verwenden" ersetzt werden, um eine Verbindung zu Raspberry Pi herzustellen. AFAIK gibt es auf RasPi keinen bidirektionalen Open-Drain-Pin. Abgesehen davon ist dies sicherlich eine überzeugende Option
Das einfache Anschließen von GPIO4 mit einem ~1,5-kΩ-Pullup an 3,3 V funktioniert hervorragend. Der Onewire-Kerneltreiber schaltet zwischen Low-Pull-Output und -Input um. Dies ist genau dasselbe wie ein bidirektionaler offener Abfluss. Der DS28E17-Kerneltreiber listet automatisch alle DS28E17 auf dem Bus auf und präsentiert sie dem Benutzer als I²C-Hosts.
"Kernel-Treiber schaltet zwischen Low-Pull-Ausgang und -Eingang um". auch bekannt als "bit banging"
Sie könnten zB auch einen DS2482-800 auf dem lokalen I²C verwenden, um 8 Onewire-Busse zu erstellen, und dann einen oder mehrere DS28E17 auf jedem dieser Busse verwenden, um entfernte I²C-Busse zu erhalten. Lediglich eine weitere I²C–Onewire Bridge hinter dem DS28E17 ist nicht ratsam. Ich habe dies in meiner Antwort bearbeitet.
Ich bin ein wenig verloren mit Ihrer Verwendung von "hinter" und wovor genau Sie warnen. Es sind nur zwei Verbindungen möglich: I2Cmaster - DS2484/DS2482-800 - 1wire oder 1wire - DS28E17 - I2Cslave. Ersteres kann durch Bitschlagen ersetzt werden.
@Maple Vielleicht dieselbe Falle, in die ich getappt bin? I2Cmaster <-> DS2484/DS2482-800 <-> 1wire <-> DS28E17 <-> I2Cslave. Wie Sie mit meiner CAN-Lösung darauf hingewiesen haben, funktioniert dies nicht?
@ThatsRightJack Das funktioniert , weil diese Chips keine Controller sind, sondern Brücken. Genau dafür sind sie gemacht.
Was "funktioniert", aber sehr scheiße ist, einen anderen DS2484 anstelle des I²C-Slaves auf dem DS28E17 zu verwenden und dann einen anderen Onewire-Abschnitt zu haben. Es ist einfach zu langsam. Ich habe den Eindruck, dass Sie so etwas planen, weil Sie von einem "Hub" gesprochen haben. Aber jetzt ist mir klar, dass Sie den Raspberry Pi "Hub" genannt haben.
Wer bei klarem Verstand würde 1-Wire in I2C und dann wieder in 1-Wire umwandeln?! Denken Sie daran, dass DS2484 nicht nur ein I2C-Slave ist. Es verfügt über interne Status- und Konfigurationsregister, die eine Verbindung zur Host-MCU voraussetzen. Ich verstehe endlich, wovor Sie warnen, aber da es sich um eine unrealistische Konfiguration handelt, hilft diese Warnung nicht, sondern schafft nur Verwirrung
Eigentlich wollte das jemand schaffen, als er nach einem DS28E17-Treiber auf der OWFS-Liste fragte. Idee war, einen Bussplitter zu haben, wie z.
@Janka Entschuldigung für die Verwirrung in meiner Terminologie (dh Verwendung des Wortes "Hub"). Wie im Bild zu sehen, soll der Raspberry Pi der zentrale Knoten sein, der alle Daten von den 5 Sensorknoten sammelt.
@Maple OK, nur zur Verdeutlichung dieser möglichen Lösung sehe ich hier die Verbindungen für die Sterntopologie: Raspberry Pi (I2Cmaster) <-> DS2482-800 ("Brücken" von i2c zu 1-Draht auf 5 einzelnen Bussen) < -> 30m Kabel (jeder der 5 Sensorzweige) <-> DS28E17 ("Brücken" 1-Draht zurück zu i2c) <-> Sensor (I2Cslave). Vielleicht kann der DS2482-800 durch Bit-Banging ersetzt werden, aber da ich 5 Busse habe, gehe ich davon aus, dass ich die Hardware verwende. Aufgrund Ihrer Kommentare glaube ich, dass dies aus kommunikativer Sicht funktionieren würde.
@ThatsRightJack Du hast es endlich richtig gemacht ;). Das Bit-Banging von 5 Bussen ist eine ziemliche Belastung für die CPU, selbst bei einem so langsamen Bus wie 1-Wire, besser bei der Hardware bleiben. Zur Not können Sie 5x DS2484-Chips auf der Pi-Seite verwenden, alle auf demselben Hardware-I2C. Ja, das würde funktionieren, aber überprüfen Sie zuerst Ihre Anforderungen an die Sensordatenraten. Wenn Sie mehr als 16 kbit benötigen, brauchen Sie etwas Besseres (Schnelleres) als 1-Draht.
@ThatsRightJack Wenn Sie andererseits viel weniger benötigen und einige Ihrer Sensoren nahe beieinander liegen, können Sie mehrere DS28E17 an verschiedenen Stellen auf denselben 1-Draht-Bus setzen und so eine gemischte Topologie erstellen.
@Maple Ja, ich werde mir die Datenraten und Leistungsdaten etwas genauer ansehen, um zu sehen, ob die Lösung funktioniert. Zumindest was die Konfiguration betrifft, waren Sie uns eine große Hilfe!
@Maple Können Sie näher erläutern, was Sie mit "aber überprüfen Sie zuerst Ihre Anforderungen an die Sensordatenraten. Wenn Sie mehr als 16 kbit benötigen, benötigen Sie etwas Besseres (Schnelleres) als 1-Draht"? Ich habe mir das Datenblatt angesehen und sehe nichts, was mir bei der Bereitstellung dieser Informationen auffällt. Vielleicht, wenn Sie so toll wären, einen kurzen Blick auf das Datenblatt ( te.com/usa-en/product-CAT-BLPS0013.html ) zu werfen und mir zu sagen, wonach ich suchen soll?
Die Konvertierung der Datenblattangaben dauert etwa 8,22 ms. Das Starten einer Konvertierung durch den DS28E17 dauert etwa 15 ms, das Lesen des Ergebnisses weitere 15 ms. Es sind also etwa 40 ms pro Sample oder 25 Samples pro Sekunde. Mit reinem I²C könnten Sie 100 Samples pro Sekunde erreichen.
@Janka 20 Bit, um eine Konvertierung zu starten, und 38 Bit, um das Ergebnis zu lesen, also werden die Zahlen etwas anders sein, aber in der gleichen Größenordnung. Ich habe theoretisch maximal 119 Samples / s für reines I2C, aber das wirkliche Leben spielt sowieso nie mit der Theorie mit.

Ich vermute, dass es andere Arten von I2C-Extendern gibt, aber ich kenne nur zwei - Puffer (wie PCA9605, P82B715) und Splitter (wie PCA9600, P82B96). Sie alle wurden entwickelt, um eine höhere Buskapazität der langen Leitungen zu isolieren, indem sie die Senkenfähigkeit der Ausgänge erhöhen. Es scheint, dass sich die Puffer jetzt alle dem EOL nähern.

Beachten Sie jedoch, dass eine Erhöhung der Senkfähigkeit im Grunde eine Erhöhung der Ströme bedeutet, was nicht gut mit Ihrer Anforderung eines geringen Stromverbrauchs verheißt.

Es gibt viele Anwendungshinweise, die ich zum Lesen empfehlen würde, wie bereits von @ali-chen AN11084 oder AN11075 , AN10658 vorgeschlagen . Interessant ist jedoch, dass selbst diejenigen von ihnen, die Twisted Pair in ihrer Topologie verwenden, immer noch auf Single-Ended-Signalisierung angewiesen sind. Ich bin mir ziemlich sicher, dass jeder Anwendungshinweis oder jedes Gerät, das Sie wählen würden, gut funktionieren sollte.

Was ich jedoch vorschlagen möchte, ist, sich zuerst dieses Gerät anzusehen . Sie beschreiben es als "PCA9600 Extender". Wie auch immer tief in der technischen Beschreibung vergraben, finden Sie eine clevere Verwendung des CAN-Transceiver-Chips PCA82C251 , um I2C-Signale (aufgeteilt auf Tx, Rx durch PCA9600) in Differenzsignale umzuwandeln.

Das Obige hat bereits ohne Abschirmung den Vorteil einer hohen Störfestigkeit. Und es kann Ihnen eine Hochgeschwindigkeitskommunikation über 100 m Entfernung ermöglichen. Aber hier ist ein weiterer Trick für Sie: Der CAN-Bus kann bei 3,3 V mit der gleichen Geschwindigkeit und Zuverlässigkeit wie bei 5 V arbeiten und gleichzeitig den Stromverbrauch um mehr als 50 % reduzieren. Ich denke, das rechtfertigt einen genaueren Blick auf Ihre Anwendung.

Dieser NXP-Hinweis skizziert Methoden, um das I2C-Bussystem auf eine Länge von über 300 m bei 60 kbit/s zu bringen, AN11084 . Die Lösungen umfassen verdrillte Leitungen, PCA9605-Repeater und verzögerungserzeugende Logik an jedem Slave. Viel Glück.

Ich plädiere auch dafür, sich das anzuschauen . https://en.m.wikipedia.org/wiki/Low-voltage_differential_signaling

Es ist immun gegen Gleichtaktrauschen, unabhängig von der Masseverbindung und läuft auch problemlos einige 10 s von Metern und bietet dennoch eine hohe Bitrate im Vergleich zum I2C-Standard.

Wenn Sie die Schaltpläne oder das Blockdiagramm der beabsichtigten Verbindung bereitstellen können, kann ein besseres Schema ausgearbeitet werden, um den Stromverbrauch weiter zu senken.

M LVDS (Multi-LVDS) kann der richtige Kandidat sein. Sie können einzelne Kanäle für I2C-Takt und Daten verwenden.

Die Datenleitung ist bidirektional, kann aber über Arbitrierung gehandhabt werden.

Raspberry Pi Zero-Verbindung zum Sensor (mit I²C- oder SPI-Bus-Schnittstelle) über eine große Entfernung
AntwortenHierDatenschutz-Bestimmungen1y, 0v