Peter Fleury - UARTs - merkwürdiges Phänomen.

[John S. (student)]

Hallo zusammen

ich habe folgende Konstellation mit den UART Routinen von Peter Fleury 
realisiert:

Ein Mega256 soll über zwei UARTS eine bidirektionale RS 232 
Kommunikation durchschleifen, Baudrate 57600 für beide Uarts, keine 
Datenflußsteuerung, 8 bits, no parity, 1 stopbit. Telegrammlänge 
zwischen 5 und 25 Bytes.

An der 1. UART Seite liegt ein anderer Mikrocontroller an, an der 2. 
UART Seite ein Profilic Umsetzer zu USB zu einem Terminalprogramm auf 
meinem PC. (Der RS232 - USB Umsetzer ist aber eher nicht das Problem, da 
das nachfolgende Problem in beiden Richtungen beim RECEIVE auftritt - 
soviel ist sicher!)

Nur zur Vervollständigung: Der 2 Mikrocontroller stellte eine TCP/IP 
Verbindung über WLAN her, die letzendlich auch (in einem TCP/IP) 
Terminalprogramm auf meinem PC endet.

Alles klappt super, bis auf das Phänomen, daß (in beiden Richtungen) 
beim Empfang des Datenstroms (sagen wir mal 5 - 25 Bytes = 1 Telegramm) 
immer nur das erste Zeichen im Mega 256 gelesen wird und dann mit ca. 12 
ms der gesamte restliche Stream, so daß ich das Telegramm in einer 
Nachverarbeitung auf dem Mega 256 wieder aus dem zuerst gesendeten 
Zeichen und den dann folgendem Rest neu konkatenieren muß. Das ist blöd, 
wenn man mit variabler Telegramm-Länge arbeitet ...! Manchmal (jedes 20. 
Telegramm, die in schneller Folge kommen) wird das Telegramm aber auch 
komplett empfangen ...!

Gefühlt stellt sich das Problem so dar: Der 1. UART Interrupt (für das 
1. gesendete Zeichen ist zu schnell abgearbeitet, so dass das Anliegen 
eines 2. (folgenden) Zeichens nicht mehr erkannt werden kann und ein 
UART_NO_DATA Status erzeugt wird. Erst danach scheint der Takt so 
synchronisiert zu sein, dass etwas länger gewartet wird und vor der 
Erzeugung des UART_NO_DATA das nächste Zeichen noch rechtzeitig erkannt 
wird.

Hat das etwas grundsätzliches mit der Snynchronisation auf einer 
ungesteuerten RS232 Verbindung zu tun ? Bleibt als einziger Ausweg, mit 
DTR und DTS zu arbeiten ? Oder kann ich die Baudrate auf dem Mega 256 
(in der Mitte) geringfügig (sagen wir mal 200 Baud) senken, um etwas 
mehr Zeit zu gewinnen ...! Oder mit 2 Stopbits arbeiten ? Oder ein 
Byte-Token vorab dem eigentlichen Telegramm versenden, um die 
Synchronisation aufzusetzen ...? Alles nicht richtig befriedigend!

Ich denke, dass es sich hier um ein typisches (generelles Problem) bei 
der Synchronisation einer asynchronisierenden Verbindung über die 
Taktung handelt. Wer kann mir dazu etwas Hintergrundwissen vermitteln? 
Was macht man am besten (minimaler Aufwand, DTR, DTS wäre die letze 
Lösung ...)

Vielen Dank und Grüsse

[Hc Z. (mizch)]

Vorab: ich kenne die von Dir verwendeten Routinen nicht.

Aber ich denke, dass Du das Problem grundsätzlich und unabhängig davon 
hast: Sobald Dein Programm schneller ist als die Frequenz, mit der die 
Zeichen eintrudeln, wirst Du die Meldung bekommen, dass keine neuen 
Daten anliegen.

> Erst danach scheint der Takt so
> synchronisiert zu sein, dass etwas länger gewartet wird und vor der
> Erzeugung des UART_NO_DATA das nächste Zeichen noch rechtzeitig erkannt
> wird.

Es gibt da nichts auf Seiten der UART-Empfangsroutinen zu 
synchronisieren:  Wenn das nächste Zeichen noch nicht eingetrudelt ist, 
muss gemeldet werden, dass nichts verfügbar ist.  Offensichtlich 
verbrauchst Du nach dem ersten Zeichen irgendwo genug Zeit, dass danach 
bei jeder Abfrage ein Zeichen zur Verfügung steht.

Die UART-Routinen können ja nicht melden, dass ein Zeichen verfügbar 
ist, wenn es noch nicht komplett da ist.  "Daten verfügbar" kann ohne 
Wahrsagekünste sonst nicht gemeldet werden.

Da hilft nur, das Protokoll so auszulegen, dass das Ende des Pakets aus 
den Daten sichtbar ist und ein Timeout darüber zu legen für den Fall, 
dass ein Zeichen verloren geht.  Zur Not geht es möglicherweise auch mit 
dem Timeout allein - aber das Protokoll (und ob genügend Zeit dafür 
verfügbar ist, jedesmal ins Timeout zu fallen) kennst nur Du.