mikrocontroller.net

Forum: PC Hard- und Software Standardverhalten für RS232-Hardwareflusskontrolle?


Autor: Sven Timotheus (uc_sven) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich baue ein kleines Druckerinterface mit einem ATmega 644, 
RS232-Anbindung zum Computer. Da der Drucker langsam ist, muss eine 
Flusskontrolle her. Ich dachte mir das so:

 * CTS: uC signalisiert Computer, ob noch Platz im Puffer ist.

 * RTS: Computer signalisiert uC, dass er noch mehr Zeichen drucken will 
(was aber wegen CTS=0 etwa nicht geht).

Die Logikprobe zeugt nun davon, dass RTS alles andere als das macht. 
Freilich wird RTS vom Terminalprogramm am Computer gesteuert. 
Hyperterminal (Win9x) setzt etwa RTS=1, sobald das Terminal verbunden 
ist, bei Trennung RTS=0. Daran lässt sich AFAIK auch nichts ändern.

Ich möchte nun eine möglichst allgemeine Umsetzung meiner 
Flusskontrolle, ohne dabei Benutzern mehr als die Grundeinstellungen 
"Baudrate und HW-Flußkontrolle" für ihr favorisiertes Terminal nennen zu 
müssen. Gibt es einen Standard? Und gibt es irgendein Terminal, das sich 
so verhält, wie ich möchte?

Sven

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTS am Computer == CTS am µC und umgekehrt.

Also der Computer benutzt sein RTS, um dem µC an dessen CTS zu 
signalisieren, daß er (der µC) senden darf.

http://www.mikrocontroller.net/articles/RS-232#Flu...

Autor: Sven Timotheus (uc_sven) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das hab ich auch zigmal gelesen. Dann müsste RTS aber doch auf 0 
gehen, wenn der Terminalprozess mal nicht (100%ige) CPU-Aufmerksamkeit 
bekommt (Standard-Multitasking - Prozess schläft, damit anderer laufen 
kann). Denn ein ausgewachsener PC hat ja dennoch "nur" den 
1-Byte-Puffer.

Defacto geht RTS bei mir aber nie auf 0.

Ist denn in RS232 soetwas vorgesehen, wie ich mir vorstelle? Ich komm 
mit den Definitionen (man wird ja überall mit den gleichen zugeworfen) 
nicht ganz klar.

Sven

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTS ist nicht dafür gedacht, konkret einzelne Daten anzufordern
oder wieder abzustellen, sondern generell dafür, daß ein DTE
(Terminal, Rechner) einer DCE (Modem) signalisiert, deren
"Sendeteil" zu aktivieren.
Deshalb wundert es mich nicht, wenn dieses Signal dauernd an ist.

Die vielen Gemeinheiten von RS232 sind eigentlich recht gut
in der c't 1986/12 S. 185-190 beschrieben (ggf. kurze Mail).

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Timotheus schrieb:
> Dann müsste RTS aber doch auf 0
> gehen, wenn der Terminalprozess mal nicht (100%ige) CPU-Aufmerksamkeit
> bekommt (Standard-Multitasking - Prozess schläft, damit anderer laufen
> kann). Denn ein ausgewachsener PC hat ja dennoch "nur" den
> 1-Byte-Puffer.
nein, das glaube ich nun nicht. Der Treiber hat ja noch ein puffer, auch 
wenn die hardware nur 1byte hat. Da der Treiber im Kernel läuft gibt es 
auch kein anderen Prozess der dabei stören kann. Und woher soll denn das 
Terminal programm wissen das es zur zeit keine CPU-Zeit hat, es gibt ja 
kein event was sagt das man nicht dran ist?

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HW-Brücken machen meist Probleme. Eigentlich reichen 3 Drähte.
Mehr da http://de.wikipedia.org/wiki/EIA-232

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Timotheus schrieb:
> Ja, das hab ich auch zigmal gelesen. Dann müsste RTS aber doch auf 0
> gehen, wenn der Terminalprozess mal nicht (100%ige) CPU-Aufmerksamkeit
> bekommt
Nein. Dieser geht erst auf 0 wenn der Puffer einen gewissen Füllstand 
erreicht hat (bspw. 2/3) da dieser idR etwa 16 bytes beträgt und die 
UART für den PC gewissermaßen in Zeitlupe arbeitet ist es recht 
wahrscheinlich das von PC Seite aus dies nie auf 0 geht.

> Ist denn in RS232 soetwas vorgesehen, wie ich mir vorstelle? Ich komm
> mit den Definitionen (man wird ja überall mit den gleichen zugeworfen)
> nicht ganz klar.
Wichtig ist es eher für den uC dem PC zu signalisieren das sein Puffer 
(fast) voll ist. Das heißt aber nicht das nach jedem Zeichen erstmal 
ein Stop signalisiert wird... dann ist schlicht die Baudrate falsch 
gewählt.
Außerdem heißt das auch nicht das der PC sofort das senden einstellt.

Daher sollte man das idR so machen:
- Senden nur wenn PC signalisiert: Okay ich bin bereit
- Wenn Empfangspuffer zu 2/3 voll --> PC um pause bitten
- Wenn Empfangspuffer bis auf 1/3 abgearbeitet --> PC signalisieren das 
man wieder bereit ist.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neben RTS/CTS gibt es auch noch DSR/DTR als Hardwaresignale. Zusaetzlich 
gibt es auch XON/XOFF als Softwaresignale.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Timotheus schrieb:
> Ja, das hab ich auch zigmal gelesen. Dann müsste RTS aber doch auf 0
> gehen, wenn der Terminalprozess mal nicht (100%ige) CPU-Aufmerksamkeit
> bekommt (Standard-Multitasking - Prozess schläft, damit anderer laufen
> kann). Denn ein ausgewachsener PC hat ja dennoch "nur" den
> 1-Byte-Puffer.

Nein. Seit 15 Jahren gibts den 16550 mit einem 16 Byte FIFO in Sende- 
und Empfangsrichtung.

Das gemeine dabei: Der FIFO ist nicht mit den Handshakeleitungen 
verbunden, denn das Handshake geschieht rein softwaremäßig. Wenn Du Dein 
RTS runternimmst, kann der FIFO noch bis zu 16 Zeichen nachliefern. 
Heißt also für Dich: Empfangspuffer hinreichend groß machen, damit kein 
Byte verloren geht.

fchk

Autor: imurlaub (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Timotheus schrieb:
> Denn ein ausgewachsener PC hat ja dennoch "nur" den
> 1-Byte-Puffer.

Hat er nicht, die im PC seit etwa Ende der 80er Jahre verbaute 
Standard-UART ist die 16550, die hat 16 Byte Hardware-FIFO. Und der 
Devicetreiber auf dem PC, der mit der UART kommuniziert, arbeitet 
interruptgesteuert und kann weitestgehend unbeeindruck von dem, was der 
PC sonst noch so treibt, die empfangenen Daten entgegegen nehmen.

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
imurlaub schrieb:
> Sven Timotheus schrieb:
>> Denn ein ausgewachsener PC hat ja dennoch "nur" den
>> 1-Byte-Puffer.
>
> Hat er nicht, die im PC seit etwa Ende der 80er Jahre verbaute
> Standard-UART ist die 16550, die hat 16 Byte Hardware-FIFO. Und der
> Devicetreiber auf dem PC, der mit der UART kommuniziert, arbeitet
> interruptgesteuert und kann weitestgehend unbeeindruck von dem, was der
> PC sonst noch so treibt, die empfangenen Daten entgegegen nehmen.

Da kennst Du aber das Interrupt-Konzept im "PC" relativ schlecht.
Dieses machte (und macht es eventuell immer noch) nämlich gerade den 
seriellen Treibern gerne mal einen Strich durch die Rechnung.

Wenn ein Festplatteninterrupt, oder der von der Tastatur, eine höhere
Priorität hat als das Teil auf der seriellen Leitung (bei dem wirklich 
Daten verloren gehen können, im Gegensatz zu dem anderen Pippifax), so 
hat gibt es ja nicht sooo viele Möglichkeiten; Ihr kennt ja alle Murphy.

Es kommt im Zweifelsfall vor, dass der Treiber für die serielle 
Schnittstelle nicht rechtzeitig reagieren kann: dann kommt es zu 
Datenverlust.

Und für die noch lernenden Experten die folgende Frechheit: Der FIFO im 
UART ist nur eine Krücke, um die Unzulänglichkeiten des PC-Designs in 
vielen Fällen zu verbergen. Dh der FIFO kann Datenverluste hinauszögern, 
muss es aber nicht, wenn nämlich die Software nicht hinterherkommt.

Autor: Sven Timotheus (uc_sven) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Urghs - von dem 16byte-FIFO im PC wusste ich tatsächlich nichts. Ich hab 
einen Zeilendrucker und will praktischerweise einfach nur eine Zeile 
einlesen und den Computer bei einer Newline/Wagenrücklauf anhalten. Wenn 
er dann allerdings bereits 16 Byte von der nächsten Zeile reinhaut, geht 
mein Konzept überhaupt nicht auf - dann muss also ein breiterer Puffer 
auf dem uC her und viel kompliziertere Logik, die daraus eine Zeile 
wurschtelt :/

Sven

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das 16 byte FIFO ist konfigurierbar. Man kann es einstellen fuer einen 
Interrupt nach 1, 4, 10 oder 14 bytes, glaub ich. Was mach der schnelle 
Hacker ? Er waehlt : 14 bytes. Was leider falsch ist. Denn dann hat das 
UART noch 2 bytes zu puffern. Ein tieferer Wert gibt dem Rechner mehr 
Zeit die Daten abzuholen.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gnadenloser Labberer schrieb:
> Das 16 byte FIFO ist konfigurierbar. Man kann es einstellen fuer einen
> Interrupt nach 1, 4, 10 oder 14 bytes, glaub ich. Was mach der schnelle
> Hacker ? Er waehlt : 14 bytes. Was leider falsch ist. Denn dann hat das
> UART noch 2 bytes zu puffern. Ein tieferer Wert gibt dem Rechner mehr
> Zeit die Daten abzuholen.

Das ändert nichts an der Tatsache, daß man auf der Gegenseite nach dem 
Ziehen von RTS noch 16 Bytes aufnehmen können muß.

fchk

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.