Discussion:
rs232 flow control: XONXOFF versus CTS/RTS
(zu alt für eine Antwort)
Tom Naxos
2003-12-10 13:31:49 UTC
Permalink
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
2003-12-10 13:51:03 UTC
Permalink
Post by Tom Naxos
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
Post by Tom Naxos
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.
Post by Tom Naxos
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
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.
Post by Tom Naxos
An welcher stelle im PC werden die XON/XOFF bytes ausgewertet.
Die muss der Sender bzw. das sendende Programm gezielt empfangen und
erkennen.
Post by Tom Naxos
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
Post by Tom Naxos
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.
Post by Tom Naxos
Wer legt diese schranke fest?
Alles was am Empfang und auswerten beteiligt ist
Post by Tom Naxos
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
Post by Tom Naxos
Mit wieviel byte
muss ein uP hier noch rechnen, bevor die pause einsetzt?
Hängt von der Reaktionszeit des Programmes ab
Post by Tom Naxos
Darf die
unterbrechung des datenstroms jederzeit angefordert werden, oder
ja
Post by Tom Naxos
nur zu bestimmten zeitpunkten (etwa zu den stoppbits).
ist egal
Post by Tom Naxos
Wo gibt es eine anstaendige dokumentation zur rs232-flusskontrolle.
Google!
Post by Tom Naxos
Via google habe ich immer nur pinbelegungen gefunden bzw. "weiche"
falsch gesucht. zu dem Thema gibt es tausende von Seiten
Post by Tom Naxos
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.
Nils Juergens
2003-12-10 16:55:11 UTC
Permalink
Post by Wolfgang Gerber
Post by Tom Naxos
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.
Post by Wolfgang Gerber
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
Rainer Zocholl
2003-12-12 21:38:00 UTC
Permalink
Post by Nils Juergens
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)
Post by Nils Juergens
(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...
Post by Nils Juergens
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?
Post by Nils Juergens
Teilweise ist sogar die Interrupt-Latenz bei moderner Hardware
deutlich schlechter als bei den guten, alten 486ern.
Ach. Send pics.
Post by Nils Juergens
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...
Joerg Wunsch
2003-12-15 09:27:35 UTC
Permalink
Post by Rainer Zocholl
(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...
Post by Rainer Zocholl
Post by Nils Juergens
(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
***@interface-systems.de http://www.interface-systems.de/~j/
Roger Steiner
2003-12-10 19:35:07 UTC
Permalink
Post by Wolfgang Gerber
Post by Tom Naxos
An welcher stelle im PC werden die XON/XOFF bytes ausgewertet.
Die muss der Sender bzw. das sendende Programm gezielt empfangen und
erkennen.
Post by Tom Naxos
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
Holger Petersen
2003-12-11 20:26:57 UTC
Permalink
Post by Roger Steiner
16550 und alle seine Derivate beherrschen flow control in Hardware.
Wirklich?
Jedenfalls das SIEMENS-Datenbuch von 1990 weiss nix davon...
Post by Roger Steiner
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
MaWin
2003-12-11 20:59:18 UTC
Permalink
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.
Gernot Zander
2003-12-12 05:21:18 UTC
Permalink
Hi,
Post by Holger Petersen
Post by Roger Steiner
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
--
<***@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
2003-12-12 21:16:29 UTC
Permalink
Post by Gernot Zander
Hi,
Ho ho ho...
Post by Gernot Zander
Post by Holger Petersen
Post by Roger Steiner
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
2003-12-13 17:52:47 UTC
Permalink
Post by Gernot Zander
Hi,
Post by Holger Petersen
Post by Roger Steiner
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
Thomas Rehm
2003-12-11 21:51:08 UTC
Permalink
Post by Roger Steiner
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.
Holger Petersen
2003-12-12 15:06:57 UTC
Permalink
Post by Thomas Rehm
Post by Roger Steiner
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
2003-12-12 19:15:05 UTC
Permalink
Post by Roger Steiner
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.
Post by Roger Steiner
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
Kurt Harders
2003-12-10 13:53:22 UTC
Permalink
Hallo Tom,
Post by Tom Naxos
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.
Post by Tom Naxos
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.
Post by Tom Naxos
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.
Post by Tom Naxos
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
Tom Naxos
2003-12-10 21:52:42 UTC
Permalink
Post by Kurt Harders
Post by Tom Naxos
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.
Post by Kurt Harders
Post by Tom Naxos
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?
Post by Kurt Harders
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
Kurt Harders
2003-12-11 07:36:02 UTC
Permalink
Hallo Tom,
Post by Tom Naxos
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...
Post by Tom Naxos
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.
Post by Tom Naxos
Post by Kurt Harders
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
2003-12-11 08:07:18 UTC
Permalink
Post by Tom Naxos
Post by Kurt Harders
Post by Tom Naxos
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.
Post by Tom Naxos
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
***@interface-systems.de http://www.interface-systems.de/~j/
Michael Schwingen
2003-12-13 17:59:38 UTC
Permalink
Post by Tom Naxos
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.
Post by Tom Naxos
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 ...
Holger Petersen
2003-12-10 21:00:30 UTC
Permalink
Post by Tom Naxos
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.
Post by Tom Naxos
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?
Post by Tom Naxos
(die echtzeit-restriktionen werden
dann nicht mehr eingehalten).
Welche?
Post by Tom Naxos
An welcher stelle im PC werden die XON/XOFF bytes ausgewertet. Per
software im kernel?
An welcher stelle im PC wird CTS/RTS ausgewertet?
In beiden Fällen kommen noch 'viele' (bei einem Standard-UART wohl
etwa 16 Bytes...
Post by Tom Naxos
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
Loading...