Schnelle Kommunikation zwischen zwei STM32

Wie weit sind die beiden STM32 Mikrocontroller voneinander entfernt?

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

Ethernet.

Hallo Malte,
wie wärs mit Ethernet?

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.

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

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.