Forum: Compiler & IDEs RS232 Flußkontrolle (CTS/RTS)


von Timebeast (Gast)


Lesenswert?

Hallo Leute,
Bin gerad dabei eine RS232 Kommunikation auf einem ATmega128 in GCC zu 
schreiben.
Klappt auch alles wunderbar. Wenn ein Zeichen ankommt, springt er in die 
ISR, schreibt UDR weg in eine Variable, die ich dann weiterverarbeite. 
Alles bestens. Jetzt zu dem Problem:
Die Daten die empfangen werden sollen, liegen in einer Datei auf dem PC 
vor (.txt). Da der uC die Daten schon wärend des Empfangs verarbeiten 
soll, suche ich nach einer Lösung die das Senden des PC´s anhalten kann. 
Die Lösung, dachte ich, ist in einer Hardware Flußkontrolle zu finden. 
Also die RTS Leitung des SUB-D Steckers auf T2out des Max232 und einen 
freien Portpin des Processors auf T2in. Das Terminal  Programm (HTerm) 
visualisiert mir auch das gesetzt sein, oder nicht, richtig.
Jetzt aber zu dem erstaunlichem:
Ich will beispielsweise drei Byte empfangen...
Sende ich sie einzeln, geht die CTS Anzeige im Terminalprogramm nach dem 
dritten Byte (zeichen) aus, und es werden keine weiteren zeichen 
gesendet. Wunderbar, genauso wie ich es haben wollte.
Jetzt nehme ich eine Datei (.txt) mit 10Byte, und, er sendet und 
empfängt diese 10Byte!! und erst danach geht die CTS Anzeige im 
Terminalprogramm aus und es kann nichts mehr gesendet werden. Es kann 
natürlich sein, bzw. ist so, das die CTS Anzeige halt auch schon nach 
3Byte aus geht, nichts desto trotz sendet der PC fröhlich weiter als 
wäre nichts!
Wenn ich dann nachdem ich die drei Byte verarbeitet habe, wieder zurück 
springe, CTS wieder auf 1 schreibe und die restlichen 7Byte erwarte, 
passiert natürlich nichts mehr...

Jemand irgendeine Idee??

Gruß Ralf

von Timebeast (Gast)


Lesenswert?

ich nochmal, vielleicht ist ja die Lösung das ich statt RTS/CTS einfach 
die Pins DTR/DSR nehmen muß? Der Unterschied zwischen diesen beiden 
würde mich auch intressieren...

von Michael U. (amiga)


Lesenswert?

Hallo,

das liegt daran, das der Sender noch seinen Buffer rausschickt, nachdem 
das "Stop" erkannt wurde. Das können je nach UART im PC etliche Zeichen 
sein, bei meinem meist 12.

Ich habe zwar für eine Geschichte Hardware-Handshake benutzt, Daten 
abholen, Stop setzen, wenn Buffer voll, weiter Zeichen abholen bis ein 
zusätzlicher Timeout zuschlägt. Geht zwar zuverläasig, war mir aber 
eigentlich fast zuviel Aufwand.

Ich nehme für solche Sachen jetzt meist das gute alte XModem, das 
schickt 128 Byte-Blöcke und wartet dann auf das ACK vom AVR.
Spart zusätzliche Leitungen und für einen 128Byte-Buffer ist bei mir 
eigentlich immer Platz im AVR.

Gruß aus Berlin
Michael

von holger (Gast)


Lesenswert?

>das liegt daran, das der Sender noch seinen Buffer rausschickt, nachdem
>das "Stop" erkannt wurde. Das können je nach UART im PC etliche Zeichen
>sein, bei meinem meist 12.

Genau, da können noch bis zu 16 Zeichen kommen wenn RTS
auf Stop gesetzt wird. Du brauchst also einen Puffer der
diese Zeichen aufnehmen kann.

von Timebeast (Gast)


Lesenswert?

hm, sehr nervig, ich meine, kein Problem mit dem Buffer, aber, wie 
Michael schon schrieb, eigendlich zu viel Aufwand, nunja...

@holger: Wie kommst Du auf 16Byte?? Bei meinen Versuchen hier, 
"verschluckt" er schon 19Byte. Gibt es da irgendeine Zahl nach der man 
sich richten kann, so in der Art, sendet noch 10ms weiter, oder, sendet 
maximal 2000Byte (die Zahl kommt im übrigen von Wikipedia, aber das kann 
ja wohl unmöglich ernst gemeint sein ;-)

Gruß
Ralf

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
Noch kein Account? Hier anmelden.