www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schnelle µC <-> µC Schnittstelle


Autor: AVR-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie kommunizieren heute denn µC miteinander? Ist Dual-Port-RAM "out"? 
Problem ist, dass Dual-Port-RAM ja kaum bezahlbar ist und die Auswahl 
auch ziemlich begrenzt ist. Habe das Gefühl die verschwinden immer mehr 
auf dem Markt. Welche Alternativen gibts zu Dual-Port-RAM bzw. wie löst 
man das heute?

Autor: A.K. (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR-User wrote:

> wie kommunizieren heute denn µC miteinander?

Ganz normal über UART, I2C, CAN.


Peter

Autor: AVR-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für übliche uC<->uC Anwendung reichen UART, SPI, I2C usw.
Falls es doch schneller sein muss, dann haben die meisten uP die dann 
eingesetzt werden einen Bus an dem RAM und Co hängen. Der muss dann halt 
dafür herhalten.

Autor: A.K. (Gast)
Datum:

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

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit SPI sind etwa 1 Megabyte pro sekunde locker möglich...

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei SPI gibt da doch eigentlich die Takrrate an und nicht die 
Datenmenge?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.

Der AVR hat ja keinen Sendepuffer.


Peter

Autor: AVR-User (Gast)
Datum:

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

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guro wrote:

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

Warum dachte ich bloß, daß AVR-user AVRs meinte.

> 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.

Nun, dann hat der Master genau das gelesen, was er hingeschickt hatte 
mit einem Byte Versatz, da er dem Slave keine Zeit zum Lesen und 
Schreiben gegeben hat.
Wie schon gesagt, der AVR hat nur das 8Bit-Schieberegister, wo er 
reinschreiben kann. Mehr als 1 Byte in Folge ist also nicht drinn.


Peter

P.S.:
SPI-Slave möchte man beim AVR nicht wirklich benutzen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guro wrote:

> ach du schreck, dann kann man beim AVR etwa nicht die slave select
> leitung über mehr als 8 bits auf 0 halten?

Auf 0 halten geht schon, bloß mit dem 2. Byte mußte halt warten.

Und der Slave kriegt ja nach jedem 8. Bit einen Interrupt.


Peter

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, vielleicht bietet dein Mikrocontroller auch die I2S Schnittstelle.

Autor: AVR-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: AVR-User (Gast)
Datum:

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

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR-User wrote:

> 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.


Wow, 800kBit mindestens, also nicht peak, das ist wirklich hart, da geht 
dann doch nur Dualport RAM.

CAN schafft zwar 1MBit, aber an Nutzdaten bleiben nur etwa 500kBit 
übrig.


Und ARM7 mit gepuffertem SPI kenne ich nur die STR71x.
Außerdem ist SPI nicht Multi-Master fähig.


Peter

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karoly Kovacs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: F.H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: guro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;-)

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(Kirchenorgel Steuerung).

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guro wrote:
>> 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 ;-)


Im Gegenteil der ist heftig am rudern.

Bei 40MHz sind das ja nur 400 Zyklen zwischen den Bytes.
Klingt erstmal viel, aber son ARM hat ja noch nen Haufen Gedöns zu 
machen, beim Eintritt und Verlassen eines Interrupts.
Und ein Main möchte man ja auch noch bedienen.
Man darf das nicht unterschätzen, was so ein RISC an Zyklen braucht, 
selbst für einfache Sachen.

Die ARM machen leider auch keinen Minimalzyklus des Main zwischen den 
Interrupts, wenn die zu häufig kommen, verreckt das Main total.


Peter

Autor: Kovacs Karoly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Jankey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.