Langsames UART mit PIC - Software oder Hardware?

"Christof Rueß" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Wenn man jedes Byte bestaetigt, wird das langsam, logisch.

50 Words sind auch nicht gerade wenig. Man sollte also Puffer einbauen, im PC sind ja 16 Byte im FIFO des UART, auf PIC-Seite baut man ihn sich selber.

Ist der Puffer fast voll, sendet man X-OFF (oder -CTS), ist er ausreichend leer ein X-ON (oder +CTS).

Das erlaubt fast volle Datenrate, vor allem gleichzeitiges ueberlappendes Senden und Empfangen. Modems sind noch ein bischen trickreicher und bestaetigen nur ganze Bloecke und auch die sogar out-of-order.

Die Umsetzung muss man ein bischen an das anpassen, was man eigentlich machen will (wenn jedes Bytes bestaetigt werden MUSS weil man nur dadurch entscheiden kann, was man als naechstes Byte sendet, ist natuerlich Essig).

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

"MaWin" schrieb:

FIFO wird meiner Meinung etwas problematisch, da die Übertragung recht spontan ist und die übertragenen Daten manchmal nur 2 Byte lang sind und manchmal auch ein paar tausend Byte. (Konkret geht es um einen RS232->MPU-Wandler für ein Grafikdisplay)

Würde sich ein solches Handshake auch nach einem Byte lohnen? Also einfach nach der Übertragung CTS kurz auf TTL-Low hängen und gleich danach wieder auf TTL-High? Wäre zumindest einiges schneller als mein überlanges Handshake.

MfG

Chris

"Christof Rueß" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Moment, bei einem FIFO spricht ja nichts dagegen, das der Thread, der die Daten aus dem FIFO rausholt, sie holt so bald welche drin sind. Man kann also problemlos auch nur 2 Byte uebertragen, es wird dabei nie X-OFF / X-ON gesendet weil der FIFO ja nie in die Naehe von voll kam. Bei 1024 Bytes werden sendeseitig jedoch alle in einem Rutsch gesendet, BIS ein X-OFF (oder CTS) eintritt, dann MUSS der Sender innerhalb des naechsten oder der naechsten Bytes anhalten, damit der als 'fast voll' signalisierte FIFO nicht 'ganz voll' wird und ueberlaeuft. Die FIFO-Behandlung ist aus Sicht des Datensende/empfangsprogramms transparent. Das stopft die Daten halt nicht mehr direkt ins Senderegister oder holt sie aus dem Empfangsregister, sondern tut und holt sie beim FIFO. Ein zweiter Prozess (Interrupt-gesteuert bzw. Hardware beim PC) packt Daten aus dem Sende-FIFO in das Sende-Register und Daten aus dem Empfangsregister in das FIFO und schickt X-ON/X-OFF bzw. steuer CTS. Es gibt sicherlich Beispielcode in den Samples der uC-Hersteller, hab aber keinen Link.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

"MaWin" schrieb:

Ok, Anfängerverständnisprobleme meinerseits ;)

Dann wird es zwar nichts mehr mit dem D/C, das ich auf DTR gelegt habe, da werde ich aber sicherlich einen Weg finden...

Google spuckte bei mir folgendes aus:

Das sieht schon mal recht gut aus - muss ich dann nur noch mit meinen Routinen verbinden.

MfG

Chris