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,
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?
Genau. Der PC leert noch seinen Puffer mit den auf der Reise befindlichen Bytes, lediglich die Software-Schicht wird angewiesen, keine weiteren Daten zu übertragen. Die Hardware spuckt dann noch ein paar Bytes aus. Kann von Board zu Board und durch die verschiedenen Chipsätze variieren.
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
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...
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.
Dreh doch mal den Puffer vom 16550 runter. Default sind wohl 16. Das scheint ein wenig viel zu sein.
> 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.
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.