mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART XON XOFF


Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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.

Autor: G. Nicht (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rufus t. Firefly,

vielen dank für deine ausführliche antwort. das hilft mir sehr weiter.

grüße,

jimbo

Autor: Ralf Rosenkranz (voltax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf Rosenkranz (voltax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Zip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Max Dm (jimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
;-)
ok super, vielen dank.

gruß, jimbo

Autor: G. Nicht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>* 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.