Geschwindigkeit der RevPi Bridge
- KarlZeilhofer
- Posts: 63
- Joined: 12 Mar 2017, 04:21
- Location: Oberösterreich, Pettenbach
- Contact:
Geschwindigkeit der RevPi Bridge
Liebes RevPi Team,
wenn ich den Code des DIO moduls richtig verstanden hab, dann wird die PiBridge mit 115200 Baud betrieben. Gibt es einen Grund für diese für RS485 eher langsame Datenrate? Ich denke 1 bis 10 MBaud sollten doch leicht machbar sein. Besonders weil differenziell und nur über 20cm.
LG, Karl
wenn ich den Code des DIO moduls richtig verstanden hab, dann wird die PiBridge mit 115200 Baud betrieben. Gibt es einen Grund für diese für RS485 eher langsame Datenrate? Ich denke 1 bis 10 MBaud sollten doch leicht machbar sein. Besonders weil differenziell und nur über 20cm.
LG, Karl
Re: Geschwindigkeit der RevPi Bridge
Hallo Karl,
wir haben mit höheren Raten experimentiert und sie wären theoretisch machbar. Wenn aber die CPU nur noch die Interrupts von der PiBridge bedienen muss, dann ist die Systemlast einfach zu hoch für das Gesamtsystem. Im RevPi Core 3 kommt hinzu, dass kein "echtes" TXenable Signal vom Kernel-Treiber für den Bustransceiver verwendet wird und somit auch durch die Art der Beschaltung dieses Transceivers eine wesentlich höhere Rate nicht wirklich EMV fest ist. Wir empfehlen für umfangreiche Datenmengen und hohe Busgeschwindigkeiten dann wirklich auf die Ethernetkanäle zurückzugreifen (bei Vollausbau ist die Buslänge übrigens über 30 cm und es kommen dann auch viele Stichleitungen dazu).
wir haben mit höheren Raten experimentiert und sie wären theoretisch machbar. Wenn aber die CPU nur noch die Interrupts von der PiBridge bedienen muss, dann ist die Systemlast einfach zu hoch für das Gesamtsystem. Im RevPi Core 3 kommt hinzu, dass kein "echtes" TXenable Signal vom Kernel-Treiber für den Bustransceiver verwendet wird und somit auch durch die Art der Beschaltung dieses Transceivers eine wesentlich höhere Rate nicht wirklich EMV fest ist. Wir empfehlen für umfangreiche Datenmengen und hohe Busgeschwindigkeiten dann wirklich auf die Ethernetkanäle zurückzugreifen (bei Vollausbau ist die Buslänge übrigens über 30 cm und es kommen dann auch viele Stichleitungen dazu).
Unser RevPi Motto: Don't just claim it - make it!
Re: Geschwindigkeit der RevPi Bridge
Der UART auf dem BCM2835 kann leider kein DMA und die RX/TX FIFOs sind mit 16 Byte recht klein. Speziell wenn man häufig und viel überträgt, ist die CPU darum stark belastet. Erhöht man die Baudrate deutlich, besteht die Gefahr dass die CPU nicht schnell genug die RX FIFO leert und es zu einem FIFO Überlauf kommt. Wir haben den UART Treiber für das stretch Image überarbeitet um noch etwas mehr Leistung rauszukitzeln, aber die kleinen FIFOs setzen uns an der Stelle Grenzen.
Die SPI Schnittstelle, die auf den Cores für die Gateway-Kommunikation benutzt wird, ist dem gegenüber deutlich angenehmer, da sie DMA kann und auch zweistellige MHz-Takte gut verkraftet.
Die SPI Schnittstelle, die auf den Cores für die Gateway-Kommunikation benutzt wird, ist dem gegenüber deutlich angenehmer, da sie DMA kann und auch zweistellige MHz-Takte gut verkraftet.
- KarlZeilhofer
- Posts: 63
- Joined: 12 Mar 2017, 04:21
- Location: Oberösterreich, Pettenbach
- Contact:
Re: Geschwindigkeit der RevPi Bridge
Vielen Dank für die Erläuterungen.
Besteht die Möglichkeit, über die Ethernetschnittstelle Informationen zu bekommen? Das ist für mich noch ein dunkler Fleck auf dem Makerboard, beosnders was die Software anbelangt.
Für die Implementierung eines normalen IO-Moduls steht nun dem Makerboard scheinbar nichts mehr im Weg.
Derzeit ist auf unserer Hardware keine Interruptleitung vom ETH-Controller an die STM32 MCU ausgeführt. Wäre diese notwendig?
LG, Karl
Besteht die Möglichkeit, über die Ethernetschnittstelle Informationen zu bekommen? Das ist für mich noch ein dunkler Fleck auf dem Makerboard, beosnders was die Software anbelangt.
Für die Implementierung eines normalen IO-Moduls steht nun dem Makerboard scheinbar nichts mehr im Weg.
Derzeit ist auf unserer Hardware keine Interruptleitung vom ETH-Controller an die STM32 MCU ausgeführt. Wäre diese notwendig?
LG, Karl
Re: Geschwindigkeit der RevPi Bridge
Hallo Karl,
ich rede mal mit der SW Abteilung, was die Online gestellt haben und was nicht und wegen des INT.
Da wir aktuell voll im Stress mit den abschließenden Tests am Stretch Image sind und die Sicherheitsupdates dazwischen gekommen sind, kann da ein wenig dauern. Aber Du hörst von uns...
ich rede mal mit der SW Abteilung, was die Online gestellt haben und was nicht und wegen des INT.
Da wir aktuell voll im Stress mit den abschließenden Tests am Stretch Image sind und die Sicherheitsupdates dazwischen gekommen sind, kann da ein wenig dauern. Aber Du hörst von uns...
Unser RevPi Motto: Don't just claim it - make it!
Re: Geschwindigkeit der RevPi Bridge
Hallo Karl,
nach Rücksprache mit den Abteilungen im Hause stellt sich die Situation so dar:
Da die Gatewaymodule ja Ursprung und Designvorgabe für die Ehternetkanäle waren, verhält sich dieses Protokoll vollständig symmetrisch zwischen beiden Partnern. Bei der Anwendung mit einem RevPi ist lediglich eines der Gateways durch den RecPi Core ersetzt. Das bedeutet aber gleichzeitig, dass der auf GitHub veröffentlichte Code für die PiBridge (nur die Ethernetkanäle) 1 zu 1 auch der Code für ein Gateway ist. Der einzige Unterschied besteht darin, dass wir im Core halt 2 Ehternetcontroller haben und das ganze 2 x abgewickelt wird (für jede Seite getrennt), während ein Gateway natürlich das Protokoll nur mit einem Controller abwickelt. Wenn Du nun also ein Modul mit Ethernet auf der PiBridge bauen willst, brauchst Du einfach nur den Code vom Core auf Deinem Modul zu implementieren und bekommst den Datenaustausch genauso, wie ihn unsere Gateways abwickeln. Insofern müsstest Du also die Informationen bereits alle haben.
Wenn Du bei der Entwicklung spezifische Fragen hast, dann melde Dich bitte direkt bei Mathias (auf Deutsch , dessen Mailadresse Du ja hast. Ob und wie Dein Ethernetcontroller dann einen INT verwendet, ist ja Sache des Ethernet-Treibers, den Du verwendest. Beim STM wird meines Wissens nach vom Hersteller ein Stack bereitgestellt, der den MPCU internen Controller mit all seinen Fähigkeiten (DMA, INT) nutzt. In unseren Gateways haben wir aber durchgängig auch den externen Controller/PHY KSZ8851 mit SPI Anbindung und INT genutzt. Die HW-Anbindung muss natürlich auch symmetrisch erfolgen. D.h. hinter dem PHY keine Magnetics, sondern eine kapazitive Ankopplung der TX Leitungen auf die PiBridge (so wie im Core).
nach Rücksprache mit den Abteilungen im Hause stellt sich die Situation so dar:
Da die Gatewaymodule ja Ursprung und Designvorgabe für die Ehternetkanäle waren, verhält sich dieses Protokoll vollständig symmetrisch zwischen beiden Partnern. Bei der Anwendung mit einem RevPi ist lediglich eines der Gateways durch den RecPi Core ersetzt. Das bedeutet aber gleichzeitig, dass der auf GitHub veröffentlichte Code für die PiBridge (nur die Ethernetkanäle) 1 zu 1 auch der Code für ein Gateway ist. Der einzige Unterschied besteht darin, dass wir im Core halt 2 Ehternetcontroller haben und das ganze 2 x abgewickelt wird (für jede Seite getrennt), während ein Gateway natürlich das Protokoll nur mit einem Controller abwickelt. Wenn Du nun also ein Modul mit Ethernet auf der PiBridge bauen willst, brauchst Du einfach nur den Code vom Core auf Deinem Modul zu implementieren und bekommst den Datenaustausch genauso, wie ihn unsere Gateways abwickeln. Insofern müsstest Du also die Informationen bereits alle haben.
Wenn Du bei der Entwicklung spezifische Fragen hast, dann melde Dich bitte direkt bei Mathias (auf Deutsch , dessen Mailadresse Du ja hast. Ob und wie Dein Ethernetcontroller dann einen INT verwendet, ist ja Sache des Ethernet-Treibers, den Du verwendest. Beim STM wird meines Wissens nach vom Hersteller ein Stack bereitgestellt, der den MPCU internen Controller mit all seinen Fähigkeiten (DMA, INT) nutzt. In unseren Gateways haben wir aber durchgängig auch den externen Controller/PHY KSZ8851 mit SPI Anbindung und INT genutzt. Die HW-Anbindung muss natürlich auch symmetrisch erfolgen. D.h. hinter dem PHY keine Magnetics, sondern eine kapazitive Ankopplung der TX Leitungen auf die PiBridge (so wie im Core).
Unser RevPi Motto: Don't just claim it - make it!
- KarlZeilhofer
- Posts: 63
- Joined: 12 Mar 2017, 04:21
- Location: Oberösterreich, Pettenbach
- Contact:
Re: Geschwindigkeit der RevPi Bridge
Vielen Dank für die ausführliche Antwort.
Die Interruptleitung werden wir also noch an die MCU anschließen und der Rest sollte eh passen.
LG, Karl
Die Interruptleitung werden wir also noch an die MCU anschließen und der Rest sollte eh passen.
LG, Karl
- Attachments
-
- makerboard ethernet v18.0.0 preliminary
- 2018-03-12_001.png (80.37 KiB) Viewed 11347 times