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?
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.
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 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.
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
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...
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.
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?
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.
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).
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...
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.
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 ;-)
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
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.
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.
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:
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.
Das ist, wie wenn ein PC-Käufer sagt: ich will eigentlich nur einen Brief schreiben, ein paar Mails checken und ein wenig im Internet browsen (alles klar: ein kleiner i3 von der Stange reicht locker), aber zusätzlich auch ab&zu einen richtig aufwendigen Egoshooter ruckelfrei spielen (hui, jetzt wirds spannend).
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?
Das ist unfair! Dagegen hat der ganze neumodische Kram doch keine Chance. Im Ernst: Mit zwei Adern ohne GND bekommt man eine UART-kompatible Halbduplex-Verbindung die keine Umschaltung braucht. Potentialtrennung gibt's gratis und das Prinzip funktioniert auch über Kilometer (ok, nicht mit 115200).
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.
Vielen Dank für Deinen hilfreichen und wertvollen Kommentar
Mit besten Grüßen
ein Industrieelektronikentwickler, der seine Produkte vor allem aus Kostengründen vorwiegend mit ausreichend galvanisch getrenntem CAN ausrüstet.
Anmerkungen:
Wenn wegen einer fehlenden 3-5€ teuren Isolationsbarriere eine viele, viele k€ teure Industrieanlage einen Stillstand hat dann freut sich nicht mal der BWLer dem sein Einsparungspotential gerade um die Ohren geflogen ist..
btw: es ist vollkommen egal ob das RS4**, RS232 oder CAN betrifft...
selbst unsere popeligen Heizungssteuerungen haben im Display seit 25 Jahren einen galvanisch isolierten CAN mit Sockel für den Transceiver damit allfällige Störimpulse keine destruktiven - und falls doch - leicht behebbare - Auswirkungen haben. Und da sind die Leitungslängen meistens kürzer als 30m....
