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?
Was immer die verwendete Hardware hergibt, für die Anwendung schnell genug ist und die jeweilig nötigen Distanzen schafft. Asynchron, SPI, I2C, CAN, ...
AVR-User wrote: > wie kommunizieren heute denn µC miteinander? Ganz normal über UART, I2C, CAN. Peter
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 ü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.
Für diese Distanz: SPI (schnell), I2C (langsamer, aber Bus, ggf. auch als Multi-Master möglich).
bei SPI gibt da doch eigentlich die Takrrate an und nicht die Datenmenge?
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
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.
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.
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 :-(
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
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?
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
> 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 ;-)
>(Kirchenorgel Steuerung).
Könnte man für sowas nicht MIDI benutzen?
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
> 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
Bitte 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.