Hi Leute, auf welche Weise können zwei STM32 Mikrocontroller am schnellsten miteinander kommunizieren? Für meine Anwendung ist es nicht so wichtig, ob die Kommunikation die CPU belastet oder nicht. Ich muss so oder so warten, bis die Daten rübergeschaufelt wurden. Welche Datenraten können erreicht werden? Hat da jemand Erfahrung? Danke für die Info! Malte
Hi Malte, welche Datenmengen sollen denn im welchen Zeitraster ausgetauscht werden? Soll/Kann es einen Master und Slave geben oder sollen z.B. beide Master sein? Gruß Microman
Malte schrieb: > Hi Leute, > > auf welche Weise können zwei STM32 Mikrocontroller am schnellsten > miteinander kommunizieren? > Für meine Anwendung ist es nicht so wichtig, ob die Kommunikation die > CPU belastet oder nicht. Ich muss so oder so warten, bis die Daten > rübergeschaufelt wurden. > Welche Datenraten können erreicht werden? > Hat da jemand Erfahrung? > > > Danke für die Info! > > Malte Na da gibt es verschiedene Möglichkeiten, abhängig von Bitrate und Leitungslänge. Der STM hat: I2C, CAN, UART, SPI. Und manche auch noch USB. Gibt 5 verschiedene Möglichkeiten. SPI über wenige cm dürfte wohl das schnellste sein. Such's Dir raus. rgds
Hi Malte, da du keinerlei Vorgaben gemacht hast schreib ich hier mal : "32bit parallel BUS" :-) Gruss Uwe
Koentest du man sagen welcher STM32 das ist? und was zur verfuegung steht? so raten nur alle im nebel rum. Ach ja die entfernung zwischen den beiden waere auch interesant.
Ethernet ist bei beiden schon belegt. Fällt also raus. Auch nicht irgendwie geroutet. Sorry, hab ich vergessen zu erwähnen. Die Controller befinden sich auf der gleichen Platine. Haben also nur ein paar Zentimeter Abstand. Mir reicht eine Master Slave Kommunikation. Vielleicht sogar unidirektional. Malte
Es geht darum Informationen aus beiden Ethernet Leitungen zu verarbeiten. Das soll einer der beiden machen. Das Ethernet soll dabei möglichst wenig ausgebremst werden.
bzw. umgekert gefragt. Was willst du den mindestens haben? Und wieveil aufwand willst du in HW / SW investieren. USB 2.0 laeft mit 480 Mbit. Wobei ich bezweifle das ein STM32 den voll auslasten kann. Und die software dahinter ist nicht zu unterschaetzen. I2C UART SPI sind da Software seiteig einfacher zu realisieren. CAN wird vermutlich ausscheiden. Vermutlich vergleichsweise langsam, Viel Protokoll overhead, und featurs die du nicht brauchst, wie stoersicherheit, Mehrere teilnemer an einem bus, ...
Malte schrieb: > Für meine Anwendung ist es nicht so wichtig, ob die Kommunikation die > CPU belastet oder nicht. Malte schrieb: > Das Ethernet soll dabei möglichst wenig ausgebremst werden. Das könnte sich widersprechen. Spätestens wenn dein Datentransfer zwischen den Controllern die Verarbeitung von Ethernet-Frames blockiert.
Da das wohl auf STM32F42x hinausläuft: Was bringst du durch den "External memory controller (FSMC)" durch wenn Du ein Dualport-Ram dazwischenhängst? Ethernet solltest Du da sogr direkt draufmappen können. Hast du die entsprechenden Pins auch frei? Viel schneller wird es wohl nicht gehen. Ohne Zwischenbaustein sieht es aber auch nicht so schlecht aus: USART1 schafft 10MBit SPI1, SPI4, SPI5 & SPI6 je 42MBit es hindert Dich niemand mehrere parallel zu verwenden. Dank DMA sollte das sogar recht komfortabel zu programmieren sein. schau Dir mal DM00053484.pdf insbesondere alles um Seite 28 herum an. viel Erfolg Hauspapa
Bruttorate für FSMC: 32Bit parallel x 60MHz = 1.9GBit Da geht aber einiges von verloren weil die Controller sich ja gegenseitig sagen müssen wann wo gültige Daten zu holen sind. fröhliches Basteln Hauspapa
Hmm, macht es da vielleicht schon Sinn einen anderen Mikrocontroller zu nehmen? Z.B. den Freescale MCF53017 (http://cache.freescale.com/files/32bit/doc/data_sheet/MCF53017.pdf?pspll=1) oder Fujitsu MB9BF616S (http://www.fujitsu.com/downloads/MICRO/fme/documentation/f01.pdf) Ich kann mir vorstellen, dass es schon ein bisschen dauert, bis die STMs so programmiert sind, dass sie zuverlässig kommunizieren. Außerdem muss ich einen Haufen Pins verdrahten und ggf. einen externen RAM verwenden. Malte
Das ist jetzt aber ein bischen unfair: Hätte jemand gesagt nimm einen anderen uC hätte es geheissen: "Das war nicht die Frage." Sag was Du vorhast, schätze die Datenrate und Latenzzeit auf die Du kommen willst. Kommen die Daten einzeln seriell oder als Pakete. Überlege ob Unidirektional, Voll- oder Halbduplex. Darüber hinaus währe interessant was Du schon kannst und kennst und dann kann man Dir auch helfen. Ich seh das nicht so dramatisch. Vermutlich kommst Du mit 160MBit von 4xSPI durch. Dazu noch ein 5. SPI für Befehle zu Datenflusssteuerung. Die Arbeit drückst Du dem DMA aufs Auge und bist recht elegant durch. Anmerken möchte ich noch das egal welche Lösung Du nimmst das Layout anspruchsvoll wird. Da ändern auch freescale und fujitsu nur wenig dran. schönes Wochenende Hauspapa
S. K. schrieb: > Ich seh das nicht so dramatisch. Vermutlich kommst Du mit 160MBit von > 4xSPI durch Mal so 'ne Frage in den Raum: ist EIN STM32F4xx nicht mit der Datenmenge von 20MB(yte)/s = 160Mbit/s ein bischen überfordert? Mag ja sein dass das Ethernet hier 2x100Mbit (brutto) hergibt, aber da wird sich ohne Flussteuerung wohl der STM als Flaschenhals erweisen. Deswegen vermute ich mal, dass die effektive Datenrate des STM die er duchpumpen kann deutlich unter 10MB/s einpendeln wird. Und deswegen denke ich wird es mit vielleicht 1...2 SPIs auch gehen. Und dann wird es mit dem Layout nicht so schwer werden. rgds
vermutlich nicht auf dauer. aber kurzzeitig wird er die schon hinbekommen. 180 MHz auf dem AHB1, 4 spi am apb2 mit 90mhz und 2 am apb1 mit 45mhz. Jeder mit einem eigenen DMA Controller. Ich vermute die SPIs haben auch noch einen FIFO, dann vermute ich mal das man alle 6 SPI kanäle mit der maximal zuläsigen bandbreite mit daten versorgen kann. nur ob der ARM die daten so schnell vararbeiten und bereitstellen kann ist eine andere frage.
abc schrieb: > nur ob der ARM die daten so schnell vararbeiten und bereitstellen kann > ist eine andere frage. Das hatte ich eigentlich gemeint. Denn was hilft's wenn ich einige wenige Pakete ganz schnell in den Speicher bekomme und die dann aber nicht abarbeiten kann. Dann lieber die ganze Strecke (Kommunikation CPU-CPU über SPI) so auslegen dass das Sinn macht. rgds
6A66 schrieb: > Dann lieber die ganze Strecke (Kommunikation > CPU-CPU über SPI) so auslegen dass das Sinn macht. Eines noch zu bedenken: Die DMA von der SPI/den SPIs unterbricht ja auch wieder die CPU (Bus wegen Speichertransfer blockiert). Wenn daher die Daten hochfrequent von der SPI in den Speicher gepumpt werden kann die CPU in dieser Ziet nur mit rezudierter Leistung arbeiten. rgds
Mein Ziel ist es, ein Ethernet Ring zu bauen, an welchem Sensoren und Aktoren hängen. Die Information soll im Kreis wandern. Daher brauche ich an jedem Device zwei Ethernet Buchsen. Ich möchte mich nicht mit der MAC-Adressvergabe, Next-Hop Listen usw. beschäftigen. Die Logik wo die Daten entlanglaufen soll sich aus der Verkabelung ergeben. Jedes Device empfängt ein Paket über Anschluss A, schaut es sich an, macht daraufhin vielleicht etwas, schreibt ggf. etwas neues ins Paket zurück und schickt es dann zum nächsten Device über Anschluss B. Also: Empfangen, verarbeiten, senden. Eine Unidirektionale Kommunikation. Geschwindigkeit max 100 MBit/s. Wie die Peripherie angeschlossen wird, schau ich mir dann an, wenn ich eine möglichst simple, zügig umzusetzende Kommunikationsstrategie habe. Wird wohl auf Serial, I2C oder SPI hinauslaufen. Gruß, Malte
Empfangen, verarbeiten, senden hört sich erstmal nicht nach unidirektionaler Kommunikation an. Ich meine, dass die Daten von Ethernet Anschluss A zum Rechenwerk und dann zum Anschluss B laufen. Nie andersrum.
Ich möchte mir allerdings die Option offen lassen, Ethernet Anschluss A für ganz normale IP Kommunikation zu nutzen.
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.