rs232 flow control: XONXOFF versus CTS/RTS

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
hallo,
ich arbeite an einem design, in dem ein 8bit microprozessor mit einem
PC verbunden ist, und zwar via rs232. Der PC soll in sehr kurzer zeit
kilobyte-weise daten an den uP schicken, ohne dass dieser ein byte
verliert. Dazu ist natuerlich irgendeine weise von flusskontrolle
notwendig.

Die idee, datenpakete vom PC zum uP zu schicken, diese quittieren zu
lassen und auf quittung die naechsten daten zu verschicken haut nicht
hin, weil die latenz im OS-kernel (hier: linux) und den fifos der
southbridge einfach zu gross ist (die echtzeit-restriktionen werden
dann nicht mehr eingehalten).

Deshalb bleibt mir nichts anderes uebrig, als XON/XOFF oder CTS/RTS
zu verwenden. Aber welches der beiden? Dazu folgende fragen:

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet. Per
software im kernel? Oder direkt im Chipsatz (sprich: southbridge).
Wenn der uP ein XOFF schickt, wieviel bytes werden ihm dann maximal
trotzdem noch zugeschickt? Wer legt diese schranke fest?

An welcher stelle im PC wird CTS/RTS ausgewertet? Mit wieviel byte
muss ein uP hier noch rechnen, bevor die pause einsetzt? Darf die
unterbrechung des datenstroms jederzeit angefordert werden, oder
nur zu bestimmten zeitpunkten (etwa zu den stoppbits).

Wo gibt es eine anstaendige dokumentation zur rs232-flusskontrolle.
Via google habe ich immer nur pinbelegungen gefunden bzw. "weiche"
texte, die zwar sagen, dass CTS/RTS neue leitungen braucht, etc,
aber obige fragen nicht klaeren.

Vielen Dank,
gruss, tom

Re: rs232 flow control: XONXOFF versus CTS/RTS
Tom Naxos schrieb:

Quoted text here. Click to load it

richtig


Versteh nicht ganz. Selbst die lahmsten XTs unter dem alten
Interpreterbasic schafften locker Baudraten bis 9600 und mehr mit
Hardware oder Softwareprotokoll.

Bei heutigen Rechnern "kann" das kein Problem mehr sein.

Quoted text here. Click to load it

Da hast du aber dann das gleiche Timingproblem! Beides muss vom Sender
explizit ausgewertet werden damit er den Versand stoppt

Quoted text here. Click to load it

Im Prinzip fast egal. Für CTS/RTS brauchst du ein paar Adern mehr im
Kabel.

Bei Xon/Xoff kannst du nicht so ohne weiteres transparent senden.

Bei reinem Ascii-Code würde ich zwecks Kabeleinsparung Xon/Xoff
nehmen.

Quoted text here. Click to load it

Die muss der Sender bzw. das sendende Programm gezielt empfangen und
erkennen.

Quoted text here. Click to load it

Den Chipsatz interessiert das nicht. Der löst nur einen INterrupt aus
und dein Programm muss sich die Empfangenen Daten abholen und
auswerten

Quoted text here. Click to load it

Das kommt drauf an wie schnell der Sender bzw sein Programm reagiert.

Quoted text here. Click to load it

Alles was am Empfang und auswerten beteiligt ist

Quoted text here. Click to load it

Ist nur ein Statussignal. Und muss auch von der Sendesoftware
ausgewertet werden. Z.B. vor jedem Byte abfragt werden ob noch
gesendet werden darf

Quoted text here. Click to load it

Hängt von der Reaktionszeit des Programmes ab

Quoted text here. Click to load it

ja


ist egal


Google!

Quoted text here. Click to load it

falsch gesucht. zu dem Thema gibt es tausende von Seiten

Quoted text here. Click to load it

stimmt nicht. RTS/CTS braucht genau 2 Leitungen. RX/TX sind nochmal 2
Leitungen. Mit GND also eine 5-adrige Verbindung minimal. Mehr braucht
man nicht.


Gruss Wolfgang
--
No reply to "From"! - Keine Antworten an das "From"
Keine privaten Mails! Ich lese die NGs, in denen ich schreibe.
We've slightly trimmed the long signature. Click to see the full one.
Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Es gibt für RTAI/LXRT einen realtime-Treiber für die serielle
Schnittstelle - vielleicht wär das ja besser geeignet.

Wolfgang Gerber wrote:
Quoted text here. Click to load it

Abgesehen davon, dass Latenz und Durchsatz nicht immer etwas miteinander
zu tun haben - wenn Du bei 9600bit/s einen (mal angenommen) 32 Byte FIFO
vollmachst, dauert das immerhin ca. 27 ms. Und das ist bei vielen
Anwendungen schon zu viel.

Teilweise ist sogar die Interrupt-Latenz bei moderner Hardware deutlich
schlechter als bei den guten, alten 486ern. Wenn der Interrupt sich erst
noch durch Southbridges, PCI-to-PCI bridges, Hypertransport, APIC etc.
zur CPU durchquetschen muss, kann das dauern :)

Gruss,

Nils


Re: rs232 flow control: XONXOFF versus CTS/RTS
  (Nils Juergens)  10.12.03 in /de/sci/electronics:


Quoted text here. Click to load it

Es sind hier(nur hier) eher 9600baud als denn 9600bit/s, es sei denn
Du hälst Start und Stopbit für "sinnvolle" Informationen die
das Fifo benötigen. Rechne lieber mit 1 Byte= ca. 1ms.
oder 9600baud = ca. 1kByte/s.


(Ein Modem das einen "Connect 9600bps" macht überträgt
tatsächlich 1200 Oktets/s, hat aber deutlich unter 9600 Baud
um die Verwirrung zu komplettieren)

Quoted text here. Click to load it

Wieso denn das?
Ich kann das FiFo mit der CPU doch schneller vollhauen als
es mit der seriellen Seite geleert wird.
Das ist doch gerade der Witz an einem Fifo...

Quoted text here. Click to load it

Emm, wenn ich alle 16ms (fifo halb voll=maximaler, sicherer Durchsatz)
mal für 10us mal am Fifo rumnuckeln muss um 16 bytes abzuholen,
ist das genau für welche Anwendung(!) zuviel?



Quoted text here. Click to load it

Ach. Send pics.

Quoted text here. Click to load it

Das ist absolut betrachtet immer noch schneller als
bei einem 8080...


Re: rs232 flow control: XONXOFF versus CTS/RTS

Quoted text here. Click to load it

Naja, ein wenig Overhead hatten sie auch...

Quoted text here. Click to load it


Nur daß der Sender gar kein FIFO hat (bzw. ein einstufiges), es geht
ja hier um den Empfänger.

Das Problem dabei sind dumme request-response Protokolle, von denen
schon UUCP vor 20 Jahren wußte, daß man sowas nicht macht, aber
heutige Hersteller erfinden die Fahrräder gern nochmal: Du willst
größere Datenmengen mit Durchsatz über die serielle Leitung schicken,
mußt aber nach jedem Byte auf die Bestätigung warten.  Da der Rx FIFO
aber dafür da ist, die Interruptrate möglichst gering zu halten, löst
er nicht sofort beim ersten empfangenen Zeichen einen Interrupt aus,
sondern wartet erst noch ein wenig, bevor er das einzelne Zeichen dann
meldet...  Damit ist die Performance komplett im Eimer.
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

16550 und alle seine Derivate beherrschen flow control in Hardware.
Wuerde bei einer UART mit FIFO sonst ja auch keinen Sinn machen.

Cheers, Roger



Re: rs232 flow control: XONXOFF versus CTS/RTS


Quoted text here. Click to load it

Wirklich?
Jedenfalls das SIEMENS-Datenbuch von 1990 weiss nix davon...

Quoted text here. Click to load it

Von den Standard-UART's kann das m.W. nur die Z80-SIO,der 6550
und der Intel 8251.

Gruss, Holger

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Nein, der kann es nur nach Datenblatt. Der hackt sich das
aktuell gesendete Byte kaputt, wenn der Pegel wechselt.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff /
We've slightly trimmed the long signature. Click to see the full one.
Re: rs232 flow control: XONXOFF versus CTS/RTS
Hi,



Quoted text here. Click to load it


#define         MCR_AFE         0x20    /* Auto flow control enable */
Damit gearbeitet habe ich aber noch nicht.

Die anderen machen es in Software, wobei das der Treiber
der untersten Ebene (also z.B. der Kernel) macht. Diesem
kann man auch sagen, den Handshake zu ignorieren (sonst könnte
man bei aufgelegtem Modem erst gar nicht wählen...).

mfg.
Gernot

--
"... wer über 30 Jahre verheiratet ist und genauso lange als
We've slightly trimmed the long signature. Click to see the full one.
Re: rs232 flow control: XONXOFF versus CTS/RTS

Quoted text here. Click to load it

Ho ho ho...


Quoted text here. Click to load it



MCR => Modem Control Register nehme ich an?!

Seite 277 aus dem o.a. Datenbuch sagt an der Stelle " immer 0 "

Wenn, dann scheint es nicht allgemein verfügbar zu sein.
Ich hatte zwar mal ein Original-Datnblatt von National,
finde das im Moment aber nicht wieder.

Gruss, Holger

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Aber nicht beim 16550. Es gibt diverse "aufgebohrte" 16550-Varianten - der
Oxford 16C950 kann z.B. diverses, was man sich schon immer gewünscht hat,
von hardware-handshake über Hardware-Xon/Xoff-handling im UART bis hin zu
sinnvollem TxEnable-Handling für RS422.

Bloß, weil der Treiber das kann, heißt das nicht, daß jeder normale 16550
das kann - bitte im richtigen Datenblatt nachlesen!

cu
Michael

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Die FIFO-UARTs können zwar Signal geben (Interrupt), wenn der FIFO
mehr oder minder voll ist, aber das hat mit dem Handshake einer
seriellen Schnittstelle nichts zu tun (wenn es diesem auch sehr
ähnlich ist).

Der sog. Hardware-Handshake ist nichts weiter als Steuerleitungen,
mit denen das eine serielle Gerät dem anderen mitteilen kann, ob
es empfangsbereit ist etc. Dieser "Hardware-Handshake" wird natürlich
per Software ausgewertet - wenn also die entsprechende Steuerleitung
als gesetzt erkannt wird, hört der Sender beispielsweise auf zu
senden.

Thomas.

Re: rs232 flow control: XONXOFF versus CTS/RTS

Quoted text here. Click to load it




Beim 16550 wohl ebenso wie bei einigen anderen 6850, ...).
Es gibt -wie ich schon schreib und MaWin leider etwas sinn-entstellend
zitiert hat- sehr wohl UART's (Z80, Intel, ...) die diesen Handshake
in Hardware durchführen. Es soll auch welche geben, denen man den Soft-
Handshake programmieren kann (ich weiss aber keine Typennummer) aber
alle o.a. Typen sind _nicht_ in einem Standard-PC eingebaut. Und sollte
eine der verschiedenen Soutbridges es können, so wäre man auf ein (oder
wenige) Motherboard's beschränkt.

Gruss, Holger

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Nope, der 16550 kann es nicht. Zumindest nicht der NS16550AFN
und alle 100% kompatiblen UARTs.


Quoted text here. Click to load it

Das verstehe ich nicht. Dank FIFO kann ich gewisse Latenzen
beim Software-RTS/CTS ohne Datenverlust ueberstehen, ich
brauche also kein Hardware-Handshake. Man muss nur den
Triggerlevel des FIFO passend setzen.

 Gerrit

Re: rs232 flow control: XONXOFF versus CTS/RTS
Hallo Tom,

Tom Naxos schrieb:

Quoted text here. Click to load it

Bei welcher Baudrate? Wenn diese Zeiten schon Probleme machen, wuerde
ich an jeder anderen Uebertragungsmethode auch Zweifel haben.

Quoted text here. Click to load it

XON/XOFF wird oberhalb des Treibers in der line-dicipline behandelt.
Also per ioctl die entsprechenden Parameter setzen. Beachte dabei, dass
beim Senden von XOFF der PC noch eine ganze Reihe Zeichen senden kann.
Das koennen, je nach Baudrate, 10-20 Zeichen werden.

Quoted text here. Click to load it

Hardware/Treiber. CTS/RTS darf zu beliebiger Zeit wechseln. Auch hier
ist zu beachten, dass der PC nicht sofort zu senden aufhoehrt. Also auch
hier einige Zeichen vorher schon CTS ausschalten.

Quoted text here. Click to load it

Das wird bei einer so altmodischen Schnittstelle schwierig :-).
Ernsthaft, es gab nie eine saubere Definition des
Schnittstellenverhaltens. Damit haben wir 1974 gekaempft und kaempfen
heute noch.

Gruss, Kurt

--
PiN - Präsenz im Netz GITmbH
Kurt Harders
We've slightly trimmed the long signature. Click to see the full one.
Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

baudrate = 115kbit/s. Es geht darum, digitale voice/telefon-daten zu
uebertragen, also genau 8000*8 = 64000 bit/s. Der Puffer im uP ist
nicht groesser als 768 byte waehlbar.

Quoted text here. Click to load it
Bedeutet "oberhalb des treibers" "im kernel"? Was soll denn
"line-dicipline" sein?

Quoted text here. Click to load it
ok, d.h. ich schicke das XOFF wenn der buffer einen fuellstand von 512
byte erreicht hat. Sollte dann klappen, oder?

gruss, tn

Re: rs232 flow control: XONXOFF versus CTS/RTS

Quoted text here. Click to load it



Ja.


Eine hardwareunabhängige Treiberschicht.

Scheint mir, Du solltest Dir mal ein Stück Schrifttum über das Design
des tty-Treibers im Unix-Kernel antun...
--
J"org Wunsch                           Unix support engineer
joerg_wunsch@interface-systems.de        http://www.interface-systems.de/~j /

Re: rs232 flow control: XONXOFF versus CTS/RTS
Quoted text here. Click to load it

Das langt doch - dann kannst Du doch RTS/CTS-Handshake machen. Du mußt die
Leitung halt nur früh genug bedienen, weil der PC noch mindestens das
sendet, was im FIFO seines UARTs ist, also beim PC16550 16 Bytes[1], plus
die Interruptlatenz auf PC-Seite - wenn Du nur 16 Bytes Puffer hättest, wäre
das eng, so sollte das aber dicke reichen. Notfalls mußt DU mit
verschiedenen Schwellen experimentieren.

Quoted text here. Click to load it

Nimm' lieber RTS/CTS, dann mußt Du Dich nicht damit rumschlagen, was Du
machst, wenn Xon/Xoff in Deinen normalen Nutzdaten vorkommen - das
Timingverhalten ist ja gleich, auch RTS/CTS wird vom Serielltreiber im
Kernel gemacht.

cu
Michael

[1] bei modernen UARTs könnte das auch mehr sein, es gibt Varianten mit 64
Bytes oder mehr FIFO ...

Re: rs232 flow control: XONXOFF versus CTS/RTS
snipped-for-privacy@gmx.net (Tom Naxos) writes:

Quoted text here. Click to load it

Also ohne Spezial-Hardware maximal 155200 Bit/Sekunde.

Quoted text here. Click to load it

was ist "kurze Zeit", wieviele KByte?

Quoted text here. Click to load it

Welche?


Quoted text here. Click to load it

Im Prinzip: Ja; genauso wie:

Quoted text here. Click to load it

In beiden Fällen kommen noch 'viele' (bei einem Standard-UART wohl
etwa 16 Bytes...

Quoted text here. Click to load it

In den Datenblättern der beteiligten Chip's?!

Nehme eventuell einen anderen UART; dir Zilog SIO-Verschnitt aus
der AFU-Ecke bietet sich eventuell an. Hat nur 3 Byte Buffer aber
die Möglichkeit, den RTS/CTS-Handshake in Hardware durchzuführen.

Viel Glück, Holger

Site Timeline