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
