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
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.C3.9Fsteuerung
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
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).
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?
HW-Brücken machen meist Probleme. Eigentlich reichen 3 Drähte. Mehr da http://de.wikipedia.org/wiki/EIA-232
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.
Neben RTS/CTS gibt es auch noch DSR/DTR als Hardwaresignale. Zusaetzlich gibt es auch XON/XOFF als Softwaresignale.
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
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.
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.
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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.