Hallo zusammen, ich habe ein Setup, bei dem ein STM32 als Slave fungiert und ein Raspberry Pi als Master. Der Raspberry Pi soll alle paar Minuten einige Bytes vom STM32 auslesen. Zusätzlich möchte ich bei Bedarf Firmware-Updates durchführen – also den STM32 über den Bootloader (ggf. eigenen Bootloader) direkt vom Raspberry Pi flashen. Zur eigentlichen Aufgabenstellung: Der STM32 und der Raspberry Pi sollen über ein rund 50 m langes Netzwerkkabel miteinander verbunden werden. Für die Kommunikation stehen mir exakt zwei Datenleitungen zur Verfügung. Diese müssen nicht zwingend I²C oder UART sein – jede zuverlässige Lösung ist denkbar, solange sie mit zwei Leitungen auskommt. Es gibt keine zusätzliche Leitung für Enable/Direction o. Ä., die komplette Kommunikation muss ausschließlich über diese beiden Signale laufen. Am STM32 habe ich 1,8 V Logikpegel, die bereits auf 3,3 V gewandelt werden. Der Raspberry Pi arbeitet ebenfalls mit 3,3 V Pegeln. Frage: Welches Übertragungssystem oder welche Schnittstelle eignet sich für eine robuste, bidirektionale Kommunikation über 50 m, wenn nur zwei Leitungen verfügbar sind – idealerweise so, dass auch Firmware-Updates vom Raspberry Pi zum STM32 möglich sind?
Manuel N. schrieb: > Es gibt keine zusätzliche Leitung für Enable/Direction o. Ä., Sind denn die GND's beider Systeme verbunden? Dann wäre CAN eine einfache und robuste Lösung. Wenn nicht, isoSPI oder Single-Pair-Ethernet.
Manuel N. schrieb: > Zusätzlich möchte ich bei Bedarf > Firmware-Updates durchführen – also den STM32 über den Bootloader (ggf. > eigenen Bootloader) direkt vom Raspberry Pi flashen. Manuel N. schrieb: > Für die Kommunikation stehen > mir exakt zwei Datenleitungen zur Verfügung. Für den Update darf man sich dann mal einen entsprechend fähigen Bootloader selbst schreiben ....
Es gibt vermutlich isolierte RS485 Treiber, die mit zwei Leitungen ohne GND auskommen.
Niklas G. schrieb: > Sind denn die GND's beider Systeme verbunden? Dann wäre CAN eine > einfache und robuste Lösung. > > Wenn nicht, isoSPI oder Single-Pair-Ethernet. Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur verfügung. SPI hat meines Kenntnisstandes mehr als zwei.
Nemopuk schrieb: > Es gibt vermutlich isolierte RS485 Treiber, die mit zwei Leitungen ohne > GND auskommen. Habe die GND's verbunden.
Wastl schrieb: > Für den Update darf man sich dann mal einen entsprechend > fähigen Bootloader selbst schreiben .... Schreibe gerne einen selbst :)
Manuel N. schrieb: > SPI hat meines Kenntnisstandes mehr als zwei. isoSPI hat genau zwei Pins, ein differentielles bidirektionales galvanisch getrenntes Paar genau wie Ethernet. Manuel N. schrieb: > Habe die GND's verbunden. Dann geht auch CAN oder RS485. CAN ist schön einfach für Multi-Master Systeme weil die Hardware schon fast alles erledigt. Bei nur zwei Endpunkten ist RS485 aber vermutlich ausreichend, und etwas praktischer bei größeren Datenmengen wie für das Firmware Update nötig.
Manuel N. schrieb: > Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur > verfügung. SPI hat meines Kenntnisstandes mehr als zwei. Durch diese Fehlplanung wird es im Endeffekt sehr teuer bzw. sehr aufwendig das Vorhaben zu realisieren. Also lieber nochmal alles von vorn, mit mehr Pins für die Kommunikation.
Niklas G. schrieb: > isoSPI hat genau zwei Pins, ein differentielles bidirektionales > galvanisch getrenntes Paar genau wie Ethernet. Aber der STM32 und RaspberryPi müssen die daten via SPI ausgeben und empfangen oder? SPI hat mehr als zwei Pins (SDO/SDI/SCK/NSS) und ich habe physisch am STM32 und RaspberryPi exakt zwei Pins zur verfügung > Dann geht auch CAN oder RS485. CAN ist schön einfach für Multi-Master > Systeme weil die Hardware schon fast alles erledigt. Bei nur zwei > Endpunkten ist RS485 aber vermutlich ausreichend, und etwas praktischer > bei größeren Datenmengen wie für das Firmware Update nötig. Habe nur zwei Endpunkte, würde daher lieber RS485 nehmen. Welche IC's empfiehlst du mir? Was für eine baudrate über 50m ist realistisch? Eine baudrate von 115200 wäre wünschenswert
Manuel N. schrieb: > Niklas G. schrieb: >> ... >> Wenn nicht, isoSPI oder Single-Pair-Ethernet. > > ... SPI hat meines Kenntnisstandes mehr als zwei. isoSPI ≠ SPI Hier kannst du deinen Kenntnisstand erweitern: ;-) https://www.analog.com/media/en/technical-documentation/data-sheets/ltc6820.pdf
:
Bearbeitet durch User
Manuel N. schrieb: > Aber der STM32 und RaspberryPi müssen die daten via SPI ausgeben und > empfangen oder? Ja. Daher muss auf beiden Seiten ein Umsetzer und Transformator dazwischen, LTC6820. Der macht aus den 4 SPI-Pins ein differentielles Paar. Manuel N. schrieb: > Welche IC's empfiehlst du mir? https://www.ti.com/product-category/isolation/isolated-interface-ics/rs-485-transceivers/overview.html
Manuel N. schrieb: > Hallo zusammen, > > ich habe ein Setup, bei dem ein STM32 als Slave fungiert und ein > Raspberry Pi als Master. Der Raspberry Pi soll alle paar Minuten einige > Bytes vom STM32 auslesen. Also nix schnelles > Zusätzlich möchte ich bei Bedarf > Firmware-Updates durchführen – also den STM32 über den Bootloader (ggf. > eigenen Bootloader) direkt vom Raspberry Pi flashen. also hat auch das Zeit - solange es zuverlässig funktioniert? > Der STM32 und der Raspberry Pi sollen über ein rund 50 m langes > Netzwerkkabel miteinander verbunden werden. Für die Kommunikation stehen > mir exakt zwei Datenleitungen zur Verfügung. Diese müssen nicht zwingend > I²C oder UART sein – jede zuverlässige Lösung ist denkbar, solange sie > mit zwei Leitungen auskommt. > > Frage: > Welches Übertragungssystem oder welche Schnittstelle eignet sich für > eine robuste, bidirektionale Kommunikation über 50 m, wenn nur zwei > Leitungen verfügbar sind – idealerweise so, dass auch Firmware-Updates > vom Raspberry Pi zum STM32 möglich sind? kA wie die Umgebung aussieht, ich würde das unter allen Umständen galvanisch getrennt ausführen, 50m sind auch inhouse nicht trivial was Störsicherheit betrifft. CAN eignet sich dafür ideal. Auch ein Bootloader der über CAN arbeitet ist kein Hexenwerk, manche uCs können das out of the box...
Mi. W. schrieb: > aussieht, ich würde das unter allen Umständen galvanisch getrennt > ausführen, 50m sind auch inhouse nicht trivial was Störsicherheit > betrifft. CAN eignet sich dafür ideal. CAN ist aber normalerweise nicht galvanisch getrennt. 50m werden bei Industrieanlagen auch oft ohne galvanische Trennung gemacht.
:
Bearbeitet durch User
Manuel N. schrieb: > Was für eine baudrate über 50m ist realistisch? Eine baudrate von 115200 > wäre wünschenswert Locker, auch 1 Mbit. Aber da du nur zwei Pins zur Verfügung hast, wird einer davon die Richtung umschalten müssen, so dass der zweite Pin sowohl RxD als auch TxD ist. Das läuft dann wohl auf eine interruptbasierte Implementierung in Software hinaus. Lässt der Rest des Systems, insbesondere das OS des Raspberry Pi so eine Implementierung zu?
Nemopuk schrieb: > Aber da du nur zwei Pins zur Verfügung hast, wird > einer davon die Richtung umschalten müssen, so dass der zweite Pin > sowohl RxD als auch TxD ist. Das läuft dann wohl auf eine > interruptbasierte Implementierung in Software hinaus. Das vereinigt doch so ziemlich alle Nachteile? Wenn das ok ist, würde ich gleich ganz normales UART mit normalen RS-232 Transceivern nehmen. Das funktioniert auf beiden Seiten sofort ohne Tricks und ohne spezielle Software. Du kannst sogar den integrierten STM32-UART-Bootloader verwenden. STM32-Reset und Start des Bootloaders funktionieren auch über diese zwei Datenadern, wenn du einen 4060 und einen Transistor spendierst. Der RPi muss dazu ein Break senden, kurz für Reset und doppelt so lang für Boot. Es gibt auch RS-232 Transceiver für 1.8V: LT2801, LT2803-1.
Nemopuk schrieb: > Aber da du nur zwei Pins zur Verfügung hast, wird > einer davon die Richtung umschalten müssen Wieso das? Dann ist es auch nicht mehr differenziell. Bus-Systeme wie USB, CAN, isoSPI kommen mit einem einzelnen differenziellen Paar aus, ohne zusätzliche Ader zur Richtungsumschaltung. Man kann einfach differenzielles RS485 über die zwei Adern betreiben. Die Umschaltung der Richtung macht man "smart" in Software. Ganz simpel z.B.: Der "Slave" (vermutlich der STM32) ist standardmäßig immer auf Empfang auf dem Leitungspaar, und der "Master" (vermutlich der PI) sendet auf Wunsch ein Datenpaket und schaltet danach sofort auf Empfang um. Der Slave empfängt dieses, bearbeitet es, schickt eine Antwort zurück und schaltet wieder auf Empfang. Wenn der Master die Antwort nicht innerhalb einer fixen Zeit (z.B. 10ms) bekommen hat, ist was schief gelaufen und der Master fängt von vorn an. USB funktioniert praktisch genau so. Man kann es noch beliebig steigern, sodass z.B. beide Seiten jederzeit spontan senden können und Kollisionen erkannt werden (wie CAN). Je nachdem wie die Anforderungen sind. Prüfsummen (CRC) und Timeouts sollte man sowieso verwenden, und den Nachrichten einen Zähler hinzufügen, sodass eine doppelt empfangene Nachricht eine Aktion nicht 2x auslöst (wenn die Antwort nicht ankam, die initiale Nachricht aber schon).
Niklas G. schrieb: > Wieso das? Weil RS485 Treiber ein Steursignal für die Ruchtungsumschaltung brauchen. Und ohne Treiber würde ich das bei der Distanz nicht mal versuchen.
Nemopuk schrieb: > Weil RS485 Treiber ein Steursignal für die Ruchtungsumschaltung > brauchen. Das muss man aber nicht über die Leitung schicken, sondern kann es lokal per GPIO in Software erzeugen.
Niklas G. schrieb: > Das muss man aber nicht über die Leitung schicken, sondern kann es lokal > per GPIO in Software erzeugen. Eben, dafür braucht er einen von zwei I/O Pins. Bleibt nur nich einer für die Daten übrig. Oder zähle ich falsch bis zwei?
Nemopuk schrieb: > Eben, dafür braucht er einen von zwei I/O Pins. Ach du meinst weil PI und STM32 keine GPIOs übrig haben? Ist das so? Beim STM32 kann man einen UART-Pin bidirektional betreiben und einen GPIO zur Richtungsumschaltung nutzen, beim PI vielleicht auch. Das ändert aber das Konzept der Übertragung auf der Leitung nicht (immer noch RS485 differenziell+bidirektional) und die Software nur marginal. Auf Seite des PI könnte man einfach einen USB-RS485 Adapter nutzen, da wird das Transmit-Enable Signal automatisch generiert...
Niklas G. schrieb: > Ach du meinst weil PI und STM32 keine GPIOs übrig haben? Ist das so? Manuel N. schrieb: > Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur > verfügung. SPI hat meines Kenntnisstandes mehr als zwei.
Nemopuk schrieb: > Niklas G. schrieb: >> Ach du meinst weil PI und STM32 keine GPIOs übrig haben? Ist das so? > > Manuel N. schrieb: >> Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur >> verfügung. SPI hat meines Kenntnisstandes mehr als zwei. Hatte ich anders interpretiert, aber OK. Beim STM32 ist es wie gesagt kein Problem dank UART mit Half-Duplex: > USART single-wire Half-duplex communication: Single-wire Half-duplex mode is selected by setting the HDSEL bit in the USART_CR3 register. ... The USART can be configured to follow a Single-wire Half-duplex protocol where the TX and RX lines are internally connected. ... The TX pin is always released when no data is transmitted. Thus, it acts as a standard I/O in idle or in reception. Auf PI-Seite nimmt man einen USB-RS485 Adapter, ggf. via Hub. In Software muss man da dann praktisch nichts machen.
Nemopuk schrieb: > Eben, dafür braucht er einen von zwei I/O Pins. Bleibt nur nich einer > für die Daten übrig. Oder zähle ich falsch bis zwei? RS-485 mit Richtungsumschaltung ist auch nur semi-duplex, d.h. auch nur eine diff. Datenleitung. Dann reicht bei geeignetem Hardwareaufbau auch ein I/O Pin für die Daten ;-)
:
Bearbeitet durch User
PS: Bei CAN ist es nochmal einfacher, da braucht es genau 2 Leitungen am Controller, den Rest erledigt der Transceiver-IC.
Rainer W. schrieb: > RS-485 mit Richtungsumschaltung ist auch nur semi-duplex, d.h. auch nur > eine Datenleitung. Dann reicht bei geeignetem Hardwareaufbau auch ein > I/O Pin für die Daten Ach was!? Nemopuk schrieb: > da du nur zwei Pins zur Verfügung hast, wird einer davon die Richtung > umschalten müssen, so dass der zweite Pin sowohl RxD als auch TxD ist.
Niklas G. schrieb: > Hatte ich anders interpretiert, aber OK. Bei der Aussage des TO sehe ich da keinen Spielraum für Interpretationen. Manuel N. schrieb: > Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur > verfügung.
Manuel N. schrieb: > Für die Kommunikation stehen mir exakt zwei Datenleitungen zur Verfügung. Denn das verleitet zur Annahme, dass lediglich 2 Kupferleitungen zwischen diesen beiden Komponenten sind. Und schlimmstenfalls muss man davon ausgehen, dass diese 2 Kupferleitungen nicht verdrillt sind. Aber ich sehe keinen Grund daraus herzuleiten, dass auf beiden Seiten nur noch 2 µC-Pins frei belegbar sind. Und zwar am besten solche µC-Pins, die nur EA können und gar keine Schnittstellenfunktion haben. Niklas G. schrieb: > Ist das so? Das ist es, warum ich Schaltpläne so liebe. Gerne dürfen in diesen **Schaltplan** dann auch Kästchen mit Fragezeichen reingemalt werden, wenn dort die fragliche Komponente rein soll.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Aber ich sehe keinen Grund daraus herzuleiten, dass auf beiden Seiten > nur noch 2 µC-Pins frei belegbar sind. > Und schlimmstenfalls muss man davon ausgehen, dass diese 2 Kupferleitungen nicht verdrillt sind. Vielleicht mal beide Beiträge des TO zusammen berücksichtigen: Manuel N. schrieb: > ein rund 50 m langes Netzwerkkabel miteinander verbunden werden. Für die > Kommunikation stehen mir exakt zwei Datenleitungen zur Verfügung. Manuel N. schrieb: > Habe im Gesamten beim STM32 und RaspberryPi nur zwei Datenpins zur > verfügung. SPI hat meines Kenntnisstandes mehr als zwei. Und der vollständigkeit halber: Manuel N. schrieb: > Habe die GND's verbunden.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.