rs232 flow control: XONXOFF versus CTS/RTS

[Tom Naxos]

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

 

[Wolfgang Gerber]

Tom Naxos schrieb:

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.

richtig

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

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.

Deshalb bleibt mir nichts anderes uebrig, als XON/XOFF oder CTS/RTS
zu verwenden.

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

Aber welches der beiden? Dazu folgende fragen:

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.

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet.

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

Per
software im kernel? Oder direkt im Chipsatz (sprich: southbridge).

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

Wenn der uP ein XOFF schickt, wieviel bytes werden ihm dann maximal
trotzdem noch zugeschickt?

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

Wer legt diese schranke fest?

Alles was am Empfang und auswerten beteiligt ist

An welcher stelle im PC wird CTS/RTS ausgewertet?

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

Mit wieviel byte
muss ein uP hier noch rechnen, bevor die pause einsetzt?

Hängt von der Reaktionszeit des Programmes ab

Darf die
unterbrechung des datenstroms jederzeit angefordert werden, oder

ja

nur zu bestimmten zeitpunkten (etwa zu den stoppbits).

ist egal

Wo gibt es eine anstaendige dokumentation zur rs232-flusskontrolle.

Google!

Via google habe ich immer nur pinbelegungen gefunden bzw. "weiche"

falsch gesucht. zu dem Thema gibt es tausende von Seiten

texte, die zwar sagen, dass CTS/RTS neue leitungen braucht, etc,

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.

 

[Kurt Harders]

Hallo Tom,

Tom Naxos schrieb:

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

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

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?

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.

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

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.

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.

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

 

[Nils Juergens]

Tom Naxos schrieb:
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).

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

Wolfgang Gerber wrote:

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.

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

 

[Roger Steiner]

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet.

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

Per
software im kernel? Oder direkt im Chipsatz (sprich: southbridge).

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

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

Cheers, Roger

 

[Tom Naxos]

Kurt Harders <news@kurt-harders.de> wrote in message news:<br78cd$3veo$1@ID-20141.news.uni-berlin.de>...

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

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

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.

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet. Per
XON/XOFF wird oberhalb des Treibers in der line-dicipline behandelt.
Bedeutet "oberhalb des treibers" "im kernel"? Was soll denn

"line-dicipline" sein?

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.
ok, d.h. ich schicke das XOFF wenn der buffer einen fuellstand von 512

byte erreicht hat. Sollte dann klappen, oder?

gruss, tn

 

[Holger Petersen]

tomnaxos11@gmx.net (Tom Naxos) writes:

hallo,
ich arbeite an einem design, in dem ein 8bit microprozessor mit einem
PC verbunden ist, und zwar via rs232.

Also ohne Spezial-Hardware maximal 155200 Bit/Sekunde.

Der PC soll in sehr kurzer zeit
kilobyte-weise daten an den uP schicken, ohne dass dieser ein byte
verliert.

was ist "kurze Zeit", wieviele KByte?

(die echtzeit-restriktionen werden
dann nicht mehr eingehalten).

Welche?

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet. Per
software im kernel?

Im Prinzip: Ja; genauso wie:

An welcher stelle im PC wird CTS/RTS ausgewertet?

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

Wo gibt es eine anstaendige dokumentation zur rs232-flusskontrolle.

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

 

[Kurt Harders]

Hallo Tom,

Tom Naxos schrieb:

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.

Wenn Du Telegramme von 320 Byte nimmst, und diese quittierst, solltest
Du eine saubere Kommunikation hinbekommen. Also: PC sendet 320 Byte. uC
verarbeitet die 320 Byte und empfaengt die naechsten 320 Byte. PC sendet
nach Quittung weiter 320 Byte...

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

line-discipline ist die Behandlung der Zeichen oberhalb der eigentlichen
Treiber-Schicht. Da kann man bei Linux z.B. eigene Protokolle (etwa
Maustreiber) einfuegen, ohne eigene Treiber schreiben zu muessen. Das
ergibt einen speziellen Protokollstack.

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.

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

Das wird so nicht klappen. Erstens bist Du mit Deinem Anwenderprogramm
viel zu weit weg vom Treiber, um sinnvoll XOFF senden zu koennen. Wenn
das klappen wuerde, koenntest Du auch die Loesung ganz oben verwenden.
Zweitens ist der Puffer im Kernel nur 512 Byte (normalerweise) gross.
Drittens ist XOFF ja ein out-of-band-Vorgang, wird also asynchron zum
Empfang gesendet. Alles in allem wuerde ich die Loesung mit einem
sinnvollen Puffer und echter Qutittung vorsehen.

Gruss, Kurt

--
PiN - Präsenz im Netz GITmbH
Kurt Harders
http://www.pin-gmbh.com

 

[Joerg Wunsch]

Tom Naxos <tomnaxos11@gmx.net> wrote:

An welcher stelle im PC werden die XON/XOFF bytes ausgewertet. Per

XON/XOFF wird oberhalb des Treibers in der line-dicipline behandelt.

Bedeutet "oberhalb des treibers" "im kernel"?

Ja.

Was soll denn
"line-dicipline" sein?

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/

 

[MaWin]

Holger Petersen <hp@kbbs.org> schrieb im Beitrag <brajuh$m5c$1@kbbs.org>...

Von den Standard-UART's kann das m.W. nur der 6550

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/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Holger Petersen]

"Roger Steiner" <digsol@email.nospam.ch> writes:

16550 und alle seine Derivate beherrschen flow control in Hardware.

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

Wuerde bei einer UART mit FIFO sonst ja auch keinen Sinn machen.

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

Gruss, Holger

 

[Thomas Rehm]

Roger Steiner wrote:

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

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.

 

[Gernot Zander]

Hi,

in de.sci.electronics Holger Petersen <hp@kbbs.org> wrote:

"Roger Steiner" <digsol@email.nospam.ch> writes:

16550 und alle seine Derivate beherrschen flow control in Hardware.

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

#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

--
<hifi@gmx.de> (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)

 

[Holger Petersen]

Thomas Rehm <Th.Rehm@T-Online.de> writes:

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

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

es empfangsbereit ist etc. Dieser "Hardware-Handshake" wird natürlich
per Software ausgewertet

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

 

[Gerrit Heitsch]

Roger Steiner wrote:

16550 und alle seine Derivate beherrschen flow control in Hardware.

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

Wuerde bei einer UART mit FIFO sonst ja auch keinen Sinn machen.

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

 

[Rainer Zocholl]

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

Abgesehen davon, dass Latenz und Durchsatz nicht immer etwas
miteinander zu tun haben - wenn Du bei 9600bit/s einen

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)

(mal angenommen) 32 Byte FIFO vollmachst, dauert das immerhin ca. 27 ms.

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

Und das ist bei vielen Anwendungen schon zu viel.

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?

Teilweise ist sogar die Interrupt-Latenz bei moderner Hardware
deutlich schlechter als bei den guten, alten 486ern.

Ach. Send pics.

Wenn der
Interrupt sich erst noch durch Southbridges, PCI-to-PCI bridges,
Hypertransport, APIC etc. zur CPU durchquetschen muss, kann das dauern

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

 

[Holger Petersen]

Gernot Zander <hifi@gmx.de> writes:

Hi,

Ho ho ho...

16550 und alle seine Derivate beherrschen flow control in Hardware.

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

#define MCR_AFE 0x20 /* Auto flow control enable */

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

 

[Michael Schwingen]

In article <brbj8e$dra$1@scorpio.in-berlin.de>,
Gernot Zander <hifi@gmx.de> wrote:

Hi,

in de.sci.electronics Holger Petersen <hp@kbbs.org> wrote:
"Roger Steiner" <digsol@email.nospam.ch> writes:


16550 und alle seine Derivate beherrschen flow control in Hardware.

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

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

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

 

[Michael Schwingen]

In article <732312d8.0312101352.72dea3bf@posting.google.com>,
Tom Naxos <tomnaxos11@gmx.net> wrote:

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.

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.

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

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

 

[Joerg Wunsch]

Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de> wrote:

(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)

Naja, ein wenig Overhead hatten sie auch...

(mal angenommen) 32 Byte FIFO vollmachst, dauert das immerhin ca. 27 ms.

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

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/