rs232 flow control: XONXOFF versus CTS/RTS

Tom Naxos schrieb:

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.

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

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.

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

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

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

Alles was am Empfang und auswerten beteiligt ist

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

Hängt von der Reaktionszeit des Programmes ab

ja

ist egal

Google!

falsch gesucht. zu dem Thema gibt es tausende von Seiten

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.
Und wenn es doch sein muss, dann muss das Subjekt mit NGANTWORT beginnen.

Hallo Tom,

Tom Naxos schrieb:

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

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.

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.

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
http://www.pin-gmbh.com

Es gibt für RTAI/LXRT e>

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

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

Cheers, Roger

Also ohne Spezial-Hardware maximal 155200 Bit/Sekunde.

was ist "kurze Zeit", wieviele KByte?

Welche?

Im Prinzip: Ja; genauso wie:

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

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

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.

Bedeutet "oberhalb des treibers" "im kernel"? Was soll denn "line-dicipline" sein?

ok, d.h. ich schicke das XOFF wenn der buffer einen fuellstand von 512 byte erreicht hat. Sollte dann klappen, oder?

gruss, tn

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/

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

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

Gruss, Holger

Holger Petersen schrieb im Beitrag ...

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:

de.sci.electronics FAQ: Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

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.

#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

--
 (Gernot Zander) www.kabelmax.de *Keine Mailkopien bitte!*
"... wer über 30 Jahre verheiratet ist und genauso lange als
 Entwicklungsingenieur arbeitet, der hat vor fast garnix Angst :-)"
 (W. Allinger in dcti)

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

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

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

Ho ho ho...

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

(Nils Juergens) 10.12.03 in /de/sci/electronics:

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)

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...

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?

Ach. Send pics.

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

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

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.

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 ...

Naja, ein wenig Overhead hatten sie auch...

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/