Allgemeine µC-Kommunikationsfrage

Ich denk die Übertragung ans LCd wird deutlich langsamer sein
als die Kommunikation per RS232, der
µC sollte es schaffen die Daten schneller an das Display
zu schaufeln als sie vom PC her kommen.
Ich kann nur das umgekehrte Problem,
das nämlich der PC deutlich langsamer als der µC ist
und der dann auf nen Acknowledge vom PC wartet bis
er weitere Daten senden kann.

>Ich denk die Übertragung ans LCd wird deutlich langsamer sein
>als die Kommunikation per RS232, der
Also ist das LCD der Flaschenhals?

>µC sollte es schaffen die Daten schneller an das Display
>zu schaufeln als sie vom PC her kommen.
Nee, der PC ist der Engpass?

>Ich kann nur das umgekehrte Problem,
Umgekehrt????
Ich blick nichtmehr durch ;)

>das nämlich der PC deutlich langsamer als der µC ist
>und der dann auf nen Acknowledge vom PC wartet bis
>er weitere Daten senden kann.

Ausprobiert habe ich es nicht, aber wenn die Baudrate hoch genug ist
müsste doch das LCD den Flaschenhals darstellen.

Ich meine RS232 und das XON/XOFF Protokoll sollten bestens dafür
geeignet sein.

Gruß, Feadi

ja, hab mich da verschrieben, hast recht ...
der PC ist der Flasachenhals definitiv.
kommt allerdings auch auf das Display an,
vor allem dem Kommunikationsweg.
parallel oder serielle Datenübertragung?
Wenn ich Dich recht verstanden hab hat der
µC selbst keine REchenoperationen durchzuführen
sondern die Daten nur durchzuschaufeln.
Ich denk das schafft er locker zwischen den
uart Daten.
Wichtig dabei: Hardware UART, die unabhängig vom
Code läuft, dann musste nur noch den Buffer abfragen
ob n Zeichen drinn liegt und das in Variable
übernehmen die dann direkt ans LCD weiter geht,
während die Hardware UART schon fürs nächste Zeichen
bereit ist.
Wenn das Display z.B. am Hardware SPI hängt
brauchste nur das eingegangene Zeichen von der
Hardware Uart an dei Harware SPI schicken,
den Rest macht der µC hardwaremäßig alleine
und Dein Programm kann derweil däumchen drehen
bis wieder was im Empfangsbuffer liegt.
AVR mit 8 MHz Quarz über 38400 baud schafft das
denk ich locker.

Was meinst du mit "Hardware UART"? Bei einem AVR mache ich doch alles
in Software. Der Puffer ist doch maximal 1 Byte. Darauf kann ich zwar
z.B in einem Receive-Interrupt reagieren, aber in einen größeren
Empfangspuffer muss ich es doch selber kopieren.
Oder meinst du was anderes?

richtig, die harwaremäßig eingebaute UART hat
nen Empfangsbuffer von einem Zeichen und
kann einen Interrupt auslösen.
Aber den Empfang eines Zeichens und das Ablegen
im Empfangsbuffer brauchste dem nicht extra
zu verklickern, das macht die UART wenn sie
richtig konfiguriert ist ohne Dein zutun
und ohne Bedarf an Code.
Mann könnts als Multitasking im kleinen bezeichnen.
Du Musst dann nur Deinem Programm beibringen:

Wenn da ist Zeichen dann schicke Zeichen nach dort.

Und das wars dann schon. Wenn Du z.B. nen ATMega verwendest
kannste das so machen. Es gibt aber auch kleinere Bausteine
z.B. unter den Tinys, die haben keine Hardware-UART.
Da muss man dann eine Softwareuart basteln, die dann
einen beliebeigen I/O-Pin für die dann verwendet.
Da ist dann der Käfer mit der UART schon ziemlich beschäftigt,
dann wirds vom Timing her schon etwas verzwickter.