Schnelle µC <-> µC Schnittstelle

Was immer die verwendete Hardware hergibt, für die Anwendung schnell 
genug ist und die jeweilig nötigen Distanzen schafft. Asynchron, SPI, 
I2C, CAN, ...

Ich meine eine direkte Kopplung (1:1) im direkten Umfeld (Abstand <=5 
cm). Da wäre doch CAN leicht übertrieben. Nutzt man heute wirklich 
einfache UART Schnittstellen dafür (als Alternative zum Dual-Port RAM)?

Für diese Distanz: SPI (schnell), I2C (langsamer, aber Bus, ggf. auch 
als Multi-Master möglich).

mit SPI sind etwa 1 Megabyte pro sekunde locker möglich...

ist SPI nicht Master <-> Slave? Von der Übertragungsrate wäre SPI 
natürlich attraktiver als I2C oder UART.

peter wrote:
> guro wrote:
>> mit SPI sind etwa 1 Megabyte pro sekunde locker möglich...

> Du träumst !
> Rein theoretisch sind max 0,5MB bei 16MHz möglich, aber praktisch nicht
> zu schaffen.

es kommt auf den µC an. der muss eine so hohe datenrate natürlich 
verkraften bzw. erzeugen können...

peter wrote:
> Du brauchst bei SPI in jedem Fall ein Handshake, damit der Slave
> mitteilen kann, wann er das nächste Byte in das Senderegister
> geschrieben hat.

man braucht kein handshake.
der master zieht die slave-select leitung runter, sendet (und empfängt 
gleichzeitig) einige bytes und zieht die /SS wieder hoch. mit dem 
hochziehen der /SS leitung ist die transaktion abgschlossen.

Yep - aber wer garantiert dir, dass bei 10 gesendet Bytes seitens des 
Empfänger alle korrekt abgenommen wurden? Es geht also nur, wenn man in 
der Transferphase keine anderen Interrupts zulässt.

peter wrote:
> Wie schon gesagt, der AVR hat nur das 8Bit-Schieberegister, wo er
> reinschreiben kann. Mehr als 1 Byte in Folge ist also nicht drinn.

ach du schreck, dann kann man beim AVR etwa nicht die slave select 
leitung über mehr als 8 bits auf 0 halten?
mir scheint fast, dass die AVRs SPI-mässig nicht so das tolle sind :-(

AVR-User soll mal ein paar Infos rüber wachsen lassen.

Welche Datenrate wird benötigt?
Wieviele Pins stehen max. zur Kommunikation zu verfügung?
Sonstige Vorgaben?

Ansonsten hilft der der Artkel weiter :

http://de.wikipedia.org/wiki/Glaskugel

Hi, vielleicht bietet dein Mikrocontroller auch die I2S Schnittstelle.

Hallo. Danke für eure Beiträge.

@Obelix

Genau Vorgaben gibts noch keine, da ich erstmal nen Überblick gewinnen 
möchte. Beide µC sollen gleichwertig behandelt werden, bzw. jederzeit 
senden können (also wenn möglich kein Master/Slave). Datenrate sollte 
mindestens bei 100 kByte/s liegen.
Achja kein AVR ;) Vermutlich ein ARM7 oder ARM9.

Dualport RAM währe dann wohl übertrieben
Ich würde mal sagen UART (RS232) oder wenn du ein Port frei hast evtl. 
was paralelles überlegen.

Warum heist du dann AVR-User?

Weil ich gerne den AVR in Hobbyprojekten einsetzte. Ich geb zu war etwas 
unpassend hier.

:-)

> Datenrate sollte mindestens bei 100 kByte/s liegen.
> Achja kein AVR ;) Vermutlich ein ARM7 oder ARM9.

Seriell ist das kein Problem; nimm µPs, die DMA anbieten. Nur so lassen 
sich große Datenmengen in 'Hintergrund' übertragen.

Neuere ARMs von NXP haben ein besseres gepuffertes SPI. Das neue heisst 
ein bischen anders und das alte gibt's auch noch, also aufpassen. Atmels 
SAM7er haben DMA, vielleicht ja auch bei SPI.

Meine Wahl fällt meistens auf den UART; ist dann auch sehr einfach zum 
debuggen, da einfach ein PC abgeschlossen werden kann um den Datenstrom 
abzuhorchen.
Falls die Geschwindigkeit des UART's nicht ausreicht, dann SPI oder 
parallel per normaler IO Ports und einem eigenen, spezifischen 
Protokoll.
Wenn mehr als zwei uC's zusammen geschaltet werden sollen, dann bietet 
sich I2C an, wobei dann die uC's vorteilsweise die I2C Schnittstelle 
bereits als Hardware integriert haben.

Einmal habe ich eine ähnliche Aufgabe gehabt, 13 µCs mit möglichst 
schnelle Kommunikation über LWL zu verbinden (Kirchenorgel Steuerung).

Mit Dual Port RAM habe ich damals auch ein bisschen experimentiert, habe 
aber damit ziemlich viele Probleme gehabt.

Dann habe es "einfach" mit UARTs gemacht. Mit ca. 600kBaud, 26 Byte 
Datenmenge in jeder 10ms funkzioniert es seit 8 Jahren tadellos. (µCs: 
Dallas 80C320 u. Atmel 89C5x)

Karoly

Moin,wenn ich genügend Pin's frei habe geht es parallel am 
schnellsten,je nach Datenmenge 4 , oder 8 Bit Übertragung,auf kurzen 
Distanzen ideal,kostet auch am wenigsten Rechenzeit,mfg

> Atmels SAM7er haben DMA, vielleicht ja auch bei SPI.
ja, haben sie.
wobei man 100kBytes/s auch ohne machen kann.
dabei schläft der ja ein ;-)

> Könnte man für sowas nicht MIDI benutzen?

Schon! Es gibt viele mögliche Lösungen zu finden (auch im Internet).

Es gibt aber ein großes Problem damit: z.B. wenn zwei Module "zu weit" 
sind.
(Bei uns war die längere Entfernung ca. 10-12meter.)
Dann - wenn ein Fehler auftritt - bei MIDI "bleibt alles so, wie es 
war".
Das heisst z.B., dass eine Pfeife "unendlich" lang lautet.

Bei meinem System, wenn ein Datenfehler auftritt, es kann "niemand" 
hören,
weil es höchstens (aber mit sehr gering Wahrscheinlichkeit) bis 2-3 
Zyklen dauert (=20-30ms). Wenn es eh länger dauert, das ist ein schweres 
HW-Fehler, das müsste man natürlich nachforschen und reparieren.

(Entschuldige bitte für mein schlechtes Deutsch, wenn es nicht klar 
war.)

Karoly

naja wenn 100%tige Sicherheit willst das die Daten richtig ankommen mit 
doch einer Ordentlichen Speed ( = Maximale Speed des Langsameren der 
Beiden Peer 2 Peer User ) + Leitungslänge auch 5km Lang sein kann nimmst 
du am besten ein 2 Wire Protkoll ...

Is rein auf Software aufgebaut, und ermöglicht dir immer Maximale 
Transfereraten was halt der jeweilige uC hergibt und bedarf keinerei 
Synchronisationsgeschichten, einziger nachteil du kannst nur Peer 2 Peer 
verwenden, was du in diesem fall ja auch vorhast