Hallo, um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren benötige ich eine Zykluszeit von weniger als 50 Mikrosekunden. Ich kann mir vorstellen, dass es möglich ist wenn ich mein eigenes Protokoll über die GPIO Pins implementiere, aber ich hätte gerne eine einfachere Lösung. Die Datenmenge beträgt ungefähr 100 MBit/s. Kann man dies beispielsweise über die SPI Pins, UART, I2C, Ethernet etc. erreichen oder gibt es eine bessere Lösung? Vielen Dank
Gast
#7073622
Scooter W. schrieb: > Hallo, > > um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren benötige > ich eine Zykluszeit von weniger als 50 Mikrosekunden Zykluszeit = X Bytes hin, verarbeiten und Y Bytes zurück. Bei 100MBit: 10Bytes pro µs Bei 100 Bytes: 10µs hin, 10µs zurück, 30µs Verarbeitung. Also ja, nimm Ethernet oder irgendwas anderes. Die notwendigen Fragen kommen dann mit Deiner Vorstellung des von Dir angedachten Systems. Also nein, es geht nicht auf einem ATTINY mit 20MHz und es geht auch nicht nebenbei wenn Du Delays von 49us für das PWM-blinken einer LED verwendest.
Scooter W. schrieb: > Hallo, > > um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren benötige > ich eine Zykluszeit von weniger als 50 Mikrosekunden. Ich kann mir > vorstellen, dass es möglich ist wenn ich mein eigenes Protokoll über die > GPIO Pins implementiere, aber ich hätte gerne eine einfachere Lösung. > Die Datenmenge beträgt ungefähr 100 MBit/s. Ganz schön viel. > Kann man dies beispielsweise über die SPI Pins, UART, I2C, Ethernet etc. > erreichen Ganz schön viele Buzzwords im Suppentopf, meinst du nicht? SPI, UART und I2C kann man bei 100Mbit/s vergessen. Ethernet kann das, aber hat auch seine Latenzen. >Vielleicht. Aber > oder gibt es eine bessere Lösung? Dazu müßte man das Problem deutlich genauer kennen.
Scooter W. schrieb: > benötige ich eine Zykluszeit von weniger als 50 Mikrosekunden Soweit kein Problem. Scooter W. schrieb: > Ich kann mir vorstellen, dass es möglich ist wenn ich mein eigenes > Protokoll über die GPIO Pins implementiere Mit den unten genannten Anforderungen (100MBit)? Vergiss es! Ohne dedizierte Hardware keine Chance. Am ehesten noch über Ethernet. Das aber auch nicht Nutzdatenrate. Scooter W. schrieb: > Die Datenmenge beträgt ungefähr 100 MBit/s. Du erzeugst also mit 20kHz 625 Byte? Woher kommen diese Daten? Scooter W. schrieb: > Kann man dies beispielsweise über die... >SPI Pins Nope. Realistisch vielleicht 20 MBit. >UART Asynchron erst Recht nicht. Du willst das ja auch irgendwie wieder empfangen können. >I2C Um Welten nicht. Am ehesten noch mit einem H7 über Ethernet. Oder ein MP1 oder ähnliches Flaggschiff. FPGA wäre auch noch eine Möglichkeit. Aber wie gesagt: woher kommen solche Datenmengen?
Moin, Der STM hat doch auch iirc irgendwelche Dual-Core-Aermchen im Programm. Da kann dann sicherlich die eine CPU recht zuegig mit der anderern CPU quaken. Gruss WK
Naja SPI würde ggf. schon gehen, wenn die Quad oder Octal SPI haben vermutlich sogar besser als Ethernet wegen weniger Overhead.. Vielleicht wäre ne SDIO auch möglich.
Scooter W. schrieb: > Ich kann mir > vorstellen, dass es möglich ist wenn ich mein eigenes Protokoll über die > GPIO Pins implementiere Anfänger unterschätzen oft völlig, welch enorm hohen Aufwand ein eigenes Protokoll bedeutet, wenn es auch einigermaßen zuverlässig sein soll. Die einfachste Lösung ist fast immer, die Aufgaben in möglichst einer CPU zu lösen, z.B. mit höherem Takt, mehr Speicher. Schon die Kommunikation innerhalb einer CPU mit mehreren Kernen erhöht deutlich die Komplexität und Fehleranfälligkeit. Oftmals lassen sich die Aufgaben auch so umstellen, daß gar keine riesen CPU-Leistung mehr benötigt wird. Die beste Optimierung ist oft einfach nur eine bessere Strukturierung und Planung. Eine räumliche Trennung macht man nur, wenn sich die Aufgaben gut separieren lassen und nur ein minimaler Datenaustausch nötig wird. Ansonsten geht die meiste CPU-Zeit allein für den Datentransport und Fehlersicherung drauf.
Scooter W. schrieb: > um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren In welcher Liga spielen die denn?
Gast
#7073987
Frag beim CERN, die schaufeln noch viel mehr Daten weg und sind glücklich damit.
Scooter W. schrieb: > um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren benötige > ich eine Zykluszeit von weniger als 50 Mikrosekunden. Ich kann mir > vorstellen, dass es möglich ist wenn ich mein eigenes Protokoll über die > GPIO Pins implementiere, aber ich hätte gerne eine einfachere Lösung. > Die Datenmenge beträgt ungefähr 100 MBit/s. Wenn die beiden Teilnehmer dicht beieinander liegen und einen FSMC haben: Dual Port Memory. https://www.renesas.com/eu/en/products/memory-logic/multi-port-memory/asynchronous-dual-port-rams/70v08-64k-x-8-33v-dual-port-ram fchk
100MBit sind bei Quad-SPI nur 25MHz. Da muss man bei ein paar Dezimetern nichteinmal differentiell übertragen und es reicht die passende Terminierung.
Gast
#7074115
Gerald M. schrieb: > 100MBit sind bei Quad-SPI nur 25MHz. Da muss man bei ein paar Dezimetern > nichteinmal differentiell übertragen und es reicht die passende > Terminierung. Klingt gut, bloß welcher Mikrocontroller hat ein Quad-SPI Slave Interface mit DMA oder Buffer? In meiner kleine beschränkten Welt gibt es das nicht.
Das stimmt, hatte mich noch nie damit beschäftigt einen Mikrocontroller als QSPI Slave zu konfigurieren. Nun, man kann natürlich auch 4 SPI Schnittstellen als Slave nehmen und die dann wieder verknüppeln. Ansonsten gehen mit vielen Stm32 auch über 100MBit SPI. Oder eben, wie mehrfach genannt, die Daten da verarbeiten wo sie anfallen. Der TO hat ja auch nicht geschrieben was er machen will.
Gast
#7074341
ethernet ginge. bei beiden µCs auf einer platine kann man auch RMII direkt "kurzschliessen", es braucht keine PHYs,
Gast
#7074435
Scooter W. schrieb: > ... oder gibt es eine bessere Lösung? Wie soll man auf diese Frage antworten, wenn du keinerlei Information zu deinem Problem rausrückst. Was steckt hinter dieser Datenrate, insbesondere wieso eine bidirektionale Kommunikation mit der von dir genannten Datenrate?
Scooter W. schrieb: > um in Echtzeit zwischen zwei STM32 Controllern zu kommunizieren benötige > ich eine Zykluszeit von weniger als 50 Mikrosekunden. Was genau heißt das? Musst du alle 50 µs ein Paket verschicken? Müssen deine Pakete innerhalb von 50 µs beim Empfänger ankommen? Oder musst du alle 50 µs ein Paket verschicken, auf der Empfängerseite verarbeiten und eine Antwort zurückschicken?
Hier gibts ggf. interessante Infos zu uC welche >=100MBit am Bus auch als Slave können sollten... https://www.eevblog.com/forum/microcontrollers/any-good-recommendation-for-a-quad-spi-slave-capable-microcontroller/
Moin, Jetzt sollte so langsam der Zeitpunkt kommen, wo der TO mitteilt, dass die CPU unbedingt auch in "Eiche furniert" erhaeltlich sein muss, weil: "sonst gildeds ned". scnr, WK
Gast
#7074511
Mit dem OctoSPI der STM32'er ginge das möglicherweise schon via DQS zur Master-Slave-Synchronisation, allerdings nur im Octal-Modus (da das Interface leider mehrere Bugs hat - DQS funtioniert nur in dem Modus). Aber für eine definitive Aussage müsste man das wohl ausprobieren, da lauern zu viele Problemstellen ... Ggf. braucht man da auch noch ein wenig Logik extern.
Gast
#7074564
Vielleicht ist dem Scooter das Ganze aber auch nicht sooooo wichtig...
Gast
#7075177
A. B, schrieb: > OctoSPI Klingt wie ein Witz, aber das gibt es tatsächlich. Erstaunlich. Früher hätte man das Parallel-Port genannt.
Gast
#7075190
Stefan ⛄ F. schrieb: > Klingt wie ein Witz, aber das gibt es tatsächlich. Erstaunlich. Früher > hätte man das Parallel-Port genannt. Nein, mit Parallel-Port hat das wenig zu tun. Immerhin wickelt das die Zugriffe auf externe Speicher völlig selbsttätig ohne CPU ab. Da steckt eine recht komplizierte (und wohl deswegen ziemlich buggy) State-Machine drin ...
Gast
#7075207
A. B, schrieb: > Immerhin wickelt das die > Zugriffe auf externe Speicher völlig selbsttätig ohne CPU ab. Das konnten die Parallel Ports vieler (nicht aller) PC ebenfalls. Das Feature hiess "ECP", wurde gerne zur Ansteuerung externer Speichermedien verwendet. Parallelen mit aktuellen Produkten sind rein zufällig :-)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.