RS232: Flusskontrolle geht nicht

asd Gast #2473499
Lesenswert?
• ▲
▼ 
Hallo,

ich hab eine Steuerung für einen mechanischen Plotter gebaut, die HPGL 
Befehle per RS232 entgegen nimmt. Da das Zeichnen langsamer geht als das 
senden brauch ich eine Flußkontrolle. Hab Xon/Xoff und die 
RTS/CTS-Methode ausprobiert, bei beiden hab ich das Problem dass Zeichen 
verloren gehen wenn der PC gestoppt und wieder gestartet wird. Pentium 4 
Motherboard mit "echter" RS232.
Wenn ich zwischen den Zeichen eine 1ms Pause mache (kann man bei 
Teraterm einstellen), dann funktioniert es. Das bremst aber die 
Überragung schon so weit aus dass bei vielen kurzen Linien wie Inkscape 
sie gern produziert die Übertragung schon der Flaschenhals wird (9600 
Baud 8N1). Die Zeichen gehen wirklich bei der Übertragung verloren, sie 
sind auch weg wenn ich das direkt beim Empfang (in der Empfangs-ISR) per 
Echo zurück schicke. D.h. es liegt nicht an einem überlaufenden 
Empfangspuffer - was mich v.a. bei der Xon/Xoff Methode gewundert hat.
Wer weiß Rat?

Viele Grüße,
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Karl H. #2473509
Lesenswert?
• ▲
▼ 
Ich denke ehrlich gesagt nicht, dass die Zeichen PC-seitig verloren 
gehen. Das wäre schon vor Jahren aufgefallen.
Wird halt ein Problem in deinem Code sein.

Wenn du die Übertragung stoppst, musst du damit rechnen, dass danach 
noch ein paar Zeichen eintrudeln, ehe dann PC-seitig tatsächlich mit dem 
Senden pausiert wird. Hast du das berücksichtigt?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Reinhard Kern Gast #2473575
Lesenswert?
• ▲
▼ 
Hallo,

ob es mehrere sind, hängt von der Implementierung ab, ein FIFO könnte 
man ja abschalten. Aber eines, manchmal auch zwei sind es ganz bestimmt, 
denn der Sender hört ja nicht mitten im gerade laufenden Zeichen auf, 
und das XOFF zu senden und zu verarbeiten geht auch nicht in Null-Zeit.

Praktisch wird das so gemacht, dass die Empfangssoftware zwar bei einem 
bestimmten Bufferfüllstand ein XOFF sendet, aber normal alles 
weiterempfängt was kommt. Wird ein niedrigerer Füllstand unterschritten, 
wird XON gesendet. Das ist eigentlich sogar einfacher als den Empfang zu 
stoppen, der Empfang und die Steuerung laufen einfach nebeneinander her, 
bzw. der vorhandenen Software wird ohne Änderung das Senden von XON/XOFF 
zugefügt. laufen weitere Zeichen bei gefülltem Buffer ein, kann man 
sicherheitshalber weitere XOFF senden, ist der Buffer leer, kann man 
jede Sekunde ein XON senden, dann startet die Übertragung sicher.

Bei der Steuerung über CTS entfällt die Übertragungszeit für das XOFF, 
ich würde es aber trotzdem genauso regeln.

Gruss Reinhard
Antwort Zitieren Bearbeiten Löschen Beitrag melden
asd Gast #2474406
Lesenswert?
• ▲
▼ 
Hmm... dann muss ich das mal näher untersuchen... ist anscheinend kein 
"well known problem"... hab leider kein Speicheroszi... bei RTS/CTS 
Methode glaube ich nicht dass allein das Entleeren des PC-Puffers schuld 
ist, ich echo ja alle von der RS232-Hardware im uC empfangenen Zeichen, 
auch wenn mein Puffer im uC schon voll wäre. CTS stoppe ich eh schon 10 
Zeichen bevor der uC-Puffer voll ist.
Es gab auch einen Unterschied zwischen Teraterm und Hyperterminal 
(Win2000). Bei Hyperterminal gingen auch Zeichen verloren wenn ich die 
Pause zwischen einelnen Zeichen auf mehrere Milisekunden gestellt hab 
(war der eigentliche Grund ein anderes Terminalprogramm zu testen). Bei 
Teraterm war der Effekt weg wenn die Pause zwischen den Zeichen auf 1ms 
oder höher war. Nur bei 0ms Pause gingen Zeichen verloren...
Ich messe nach Neujahr weiter... vielen Dank für die Hinweise...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #2474414
Lesenswert?
• ▲
▼ 
Da würde ich mal abseits vom jetzigen Programm ein Testprogramm 
aufsetzen, welches nur ein Echo macht und zb auf Tasterdruck XON/XOFF 
bzw RTS/CTS bedient.

Hyperterminal kann zb eine Textdatei senden. Das würde ich mal machen 
lassen und am µC auf den Taster drücken. Wenns dann weitergeht muss auch 
der Text am PC sauber weiterlaufen ohne dass etwas fehlt.

Wenn das klappt, dann weißt du, dass du das Problem in deinem echten 
Programm irgendwo suchen musst (Buffer-Overflow, bei Interrupt Empfang 
Interrupts zu lange gesperrt, ...) und der PC unschuldig ist.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
asd Gast #2487355
Lesenswert?
• ▲
▼ 
> Default sind wohl 16. Das scheint ein wenig viel zu sein.

Ich gebe mal Rückmeldung: Der Puffer wars. Ich hab das uC Programm so 
verstellt dass Xoff bzw. CTS bei noch 20 freien Stellen im 
Empfangspuffer gesendet wird, schon ging die Übertragung einwandfrei, 
egal ob Hardware-Flusskontrolle oder Xon/Xoff. Der PC schickt 
tatsächlich noch den ganzen restlichen Puffer bevor er eine Sendepause 
einlegt.
Vielen Dank für eure Tipps.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren