hallo zusammen, hat von euch jemand vielleicht einen link in welchem erklärt wird wie man ein xon xoff implementiert? vielen dank im voraus. grüße jimbo
Da gips nix zu implementieren, das sind ganz einfache ASCII Steuerzeichen: The ASCII Code for XON is Hex 11 (DC1) and for XOFF Hex 13 (DC3).
hallo Dieter, vielen dank für die antwort. ja das hab ich auch so gemacht, dh. hab eine isr zum senden und eine zum empfangen. jedesmal wenn ich dann ein zeichen erhalten habe setze ich xoff bis ich es verarbeitet habe dann wieder xon. so das funktioniert nicht richtig. außerdem muss ich doch darauf achten ob mir das endgerät ein xoff sendet oder nicht, bevor ich senden will? gruß, jimbo
> jedesmal wenn ich dann ein zeichen erhalten habe setze ich > xoff bis ich es verarbeitet habe dann wieder xon. Für jedes EINZELNE ZEICHEN?! Das bedeutet, daß Du -abgesehen vom Nutzinhalt- doppelt soviele Zeichen versendest, wie Du empfängst. Xon/Xoff ist nur dann zu verwenden, wenn Du in Deiner Empfangsroutine einen FIFO verwendest, und dessen Füllstand einen gewissen Pegel (80% voll o.ä.) überschreitet (dann XOFF senden) bzw. einen gewissen anderen Pegel (20% voll o.ä.) unterschreitet (dann XON senden). Wichtig ist, daß Du XOFF bereits VOR dem Fifo-Voll sendest, damit ein langsam auf XOFF reagierender Sender nicht sofort Datenverlust produziert. Also auch nachdem Du XOFF gesendet hast, musst Du weiterhin einige Bytes Daten empfangen & speichern können. Empfängst Du ein XOFF, dann solltest Du in Deiner ISR das Senden einstellen und erst dann wieder damit anfangen, wenn Du ein XON empfängst. Weder XON noch XOFF müssen von der Empfangs-ISR in den FIFO eingetragen werden ... Das Senden wirst Du höchstwahrscheinlich auch über eine ISR implementieren, die einen Sende-FIFO leert. Und diese ISR muss das von der Empfangs-ISR gesetzte Flag "XOFF empfangen" bzw. "XON empfangen" auswerten. Auch musst Du Dir Gedanken darum machen, wie Du am von der Sende-ISR gesendeten FIFO vorbei die für Deine Ablaufsteuerung wichtigen XOFF- und XON-Bytes senden kannst.
Software-handshake mit XON/XOFF ist nur sinnvoll, wenn Du Ein- und Ausgaben pufferst (Ringpuffer). Beim Senden kann der Empfänger (genauer das empfangende Gerät) ein XOFF ausgeben, um den Sender warten zu lassen. Daher müssen XON/XOFF beim Empfangen immer direkt ausgefiltert und verarbeitet werden ohne in den Puffer zu gelangen. Sinnvollerweise sendet der Empfänger erst dann ein XOFF, wenn sein RX-Puffer z.B. zu 90% gefüllt ist. XON wird erzeugt, wenn der Empfangspuffer z.B. wieder zu 50% frei geworden ist.
Hallo Rufus t. Firefly, vielen dank für deine ausführliche antwort. das hilft mir sehr weiter. grüße, jimbo
Hallo Max, bei mir klappte das auch nicht, selbst mit einem 16 Byte langen Ringpuffer in der Empfangs-ISR gabs immer wieder verlorene Zeichen. Es ging erst nachdem ich im angeschlossenen Terminal-Programm (Windows Hyperterminal) zusätzlich eine kleine Wartezeit von 5ms nach jedem Zeichen und 20ms nach jedem CR eingestellt hatte. Grüße Ralf
>Es ging erst nachdem ich im angeschlossenen Terminal-Programm (Windows >Hyperterminal) zusätzlich eine kleine Wartezeit von 5ms nach jedem >Zeichen und 20ms nach jedem CR eingestellt hatte. Wenn es nicht klappt, ist es nicht ratsam mit irgendwelchen Wartezeiten herumzuspielen. Wichtig ist, wie Rufus geschrieben hat, 1. sendeseitig XON/XOFF mit höchster Priorität auszugeben und empfangsseitig auszuwerten und 2. immer den Zustand von XON/XOFF als Status gespeichert zu halten, um die Datenübertragung nicht dauerhaft zu blockieren. Wenn z.B. der RX-Puffer gelöscht wird, muß ggf. auch noch ein XON gesendet werden.
Hallo Ralf, vielen dank erstmal für deine antwort. in meinem fall kommunieziere ich nicht mit dem windows terminal. ich versuche über meinen mikrocontroller ein gps modul über at kommandos anzusprechen. kann also auf der seite des gps moduls keine verzögerungszeiten einfügen, wenn ich dich richtig verstanden habe das du die verzögerung im terminal eingestellt hast. kann nur die baudraten kleiner einstellen. grüße, jimbo
Hallo G. Nicht so wie Rufus schrieb isses ja auch richtig, aber offenbar hält sich das Windows-Hyperterminal nicht daran, es scheint als sende es munter weiter, nachdem der AVR sein XOFF abgesetzt hat (XON/XOFF-Protokoll war selbstverständlich aktiviert). Mir scheint es so, dass erst die kleine Wartezeit nach jedem Zeichen bewirkt, dass sich Hyperterminal mit seinem Empfangspuffer befasst, und das empfangene XOFF findet. Andere Frage: Wie groß (in Bytes) sollte denn der AVR-seitige Empfangspuffer sein? Grüße Ralf
>Andere Frage: Wie groß (in Bytes) sollte denn der AVR-seitige >Empfangspuffer sein? Nach Möglichkeit so groß, daß ein kompletter Datensatz in einem Stück reinpaßt. Wenn ich nen 128er verwende, nehme ich meist je 100 Byte für RX und TX. Selbst bei kleineren AVRs nehme ich mindestens 20-30 Byte.
Wichtig bei XON/XOFF ist, dass NACH dem Senden von XOFF noch genügend Platz im Puffer ist, um bereits im Sendefifo der PC-Hardware stehende Zeichen noch aufnehmen zu können. 16-Byte-Fifos sind Standard, es sollten nach dem Senden von XOFF also noch MINDESTENS 20 Byte in den Eingangspuffer passen. Besser mehr, damit Deine ATmega-Firmware auch mit der nächsten PC-Generation noch kompatibel ist (obwohl an der RS232-Schnittstelle wohl nicht mehr aufgebohrt wird, wahrscheinlicher ist sie in der nächsten PC-Generation überhaupt nicht mehr zu finden). Ich selbst sende XOFF, wenn noch 32 Bytes im Puffer frei sind und habe damit noch keine Probleme bekommen. Mit HW-Handshake KANN (muss aber nicht) sich übrigens dasselbe Problem ergeben. Wieviel Platz im Puffer <VOR> dem XOFF ist, ist im Prinzip egal. Bei größerem Puffer muss Dein ATmega seltener XOFF senden, also nimm einen großen Puffer, wenn Du den Speicher hast. Um Datenverlust zu vermeiden, ist der Platz <NACH> dem XOFF wichtig. Gruß, Stefan
@Stefan Das mit den 16Byte im FIFO des PC ist ein interessanter Aspekt. Probleme mit der Übertragung hatte ich bislang nie eingangsseitig (AVRs sind schnell :-) sondern immer nur mit langsamen Ausgabegeräten (ser. Drucker). Wenn sich µPs untereinander austauschen, kann man Handshake vermeiden, indem der Empfänger den Empfang eines Datensatzes gültig oder ungültig quittieren muß (was letztlich ja auch handshake ist).
@all: Bei XON-XOFF-Handshake nicht vergessen: nur ASCII-Daten senden! Bei Binärdaten können Datenbytes als XON und XOFF fehlinterpretiert werden! @G.Nicht: >Wenn sich µPs untereinander austauschen, kann man Handshake vermeiden, >indem der Empfänger den Empfang eines Datensatzes gültig oder ungültig >quittieren muß (was letztlich ja auch handshake ist). Das funktioniert zwischen einzelnen uc ganz gut. Zwischen PC und uc kann man sich aber auf diese Art einen Flaschenhals einbauen, spätestens, wenn statt der RS232-Direktverbindung ein RS232-USB, RS232-Ethernet oder gar RS232-WLAN-Umsetzer ins Spiel kommt: HW- oder XON-XOFF-Handshake wird bei diesem "virtuellen" Schnittstellen vor Ort erledigt. Ein blockweises Handshake muss dagegen immer erst zum Ziel-PC und auch wieder zurück. Bei USB bedeutet das z.B.: jeder Block dauert mindestens 2 frames (entspricht 2ms), jeweils einer für Datenübertragung und Quittierung. Der Effekt wird umso relevanter, je kleiner die Blöcke und je höher die Baudrate ist (bei 9600 Baud ist das ziemlich irrelevant, bei 1Mbaud sollte man sich etwas anderes überlegen). Ich kann mich noch gut an die Diskussion um Peters Bootloader erinnern: der lief ziemlich fix an der "normalen" RS232-Schnittstelle, sobald aber ein ftdi-Umsetzer dazwischenhing, wurde die Sache quälend langsam (ca. Faktor 10, wenn ich mich recht erinnere). Viele Grüße, Stefan
Leute, es euch bekannt, dass das XON/XOff nur Sinn macht wenn man die Datenstroenme nicht im Griff hat ? Wenn man naemlich beide Seiten der Kommunikation macht, sollte man die Datenstroeme im Griff haben. Dann wird auf PC seite nur soviel versandt wir auch empfangen werden kann. Die naechst bessere Loesung wuerde RTS/CTS & DSR/DRT heissen. 2 Draehte mehr. Z.
@Zip: Kannst Du das etwas näher erläutern? Hat ein Plotter, dem Du ein File schickst, seinen Datenstrom nicht im Griff, weil er ohne Handshake Deine Zeichnung nur zur Hälfte ausdruckt? grübel ... Stefan
hallo nochmal, da das thema rts/cts gefallen ist, also hw-flusskontrolle. sorgt diese flusskontrolle für eine quittierung für jedes byte oder hat sie die selbe funktionsweise wie xoff bei welcher noch ein paar bytes kommen können. gruß, jimbo
Ist identisch. RTS/CTS hat 3 Vorteile * es muss kein Zeichen übertragen werden, d.h. es muss auch kein Zeichen in den regulären Datenstrom eingeflochten werden. * man muss lokal keinen Status mitführen. Vor dem Senden einfach die entsprechende Leitung checken, ob sie freigegeben ist und gut ists. Ob die Gegenstelle das aber auch so sieht, darauf würde ich mich nicht verlassen. * man hat endlich Verwendung für die zusätzlichen Adern, die im Kabel vor sich hingammeln.
>* man hat endlich Verwendung für die zusätzlichen Adern, die im > Kabel vor sich hingammeln. Wie, Du hast noch nicht auf Lichtleiter umgestellt ? Software-handshake kommt mit weniger Leitungen aus - im Extremfall mit nur einer (Telefon-Modem, Klingeldraht, ...). @Stefan Bei Datenpaketen muß man immer Timeouts und Wiederholfunktionen vorsehen. Und daß diese Timeouts bei PC-Anbindung besonders lang sein müssen, liegt an diesen blöden Betriebssystemen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.