-----Original Message----- From: Konrad Rosenbaum [SMTP:htw6966@htw-dresden.de] Sent: Thursday, April 13, 2000 7:07 PM To: lug-dd@schlittermann.de Subject: Re: [Lug-dd] Serielle Schnittstelle
On Thu, 13 Apr 2000, did karl-heinz.fandrey@amd.com mean:
ich bin mal wieder heiss am programmieren und will die serielle Schnitstelle bedienen - vielleicht wird das ja sogar mal ein richtig nettes QSerialDevice oder so.
[cut]
Was ich nun aber gerne wissen wuerde, ist der Zeitpunkt, an dem der Sendepuffer der Schnittstelle _leer_ ist. Ueber den SocketNotifier bekomme ich nur raus, wann Platz im Sendepuffer ist.
Soweit ich weiss senden serielle Schnittstellen ihre Daten sofort raus. Das QSerialDevice sollte also herausbekommen, wann alles durch ist.
Ja, sie tun so ... Die serielle Schnittstelle ist naemlich gepuffert! Also kann ich einige Bytes reinschreiben, die dann schleunigst gesendet werden. Im Normalfall reicht es ja auch, wenn ich weiss, dass alles gesendet wird! Ich brauche nun aber die Zeit, wann alles gesendet ist (ueber den Draht, nicht in den Puffer). Mit fcntl-calls kann ich wahrscheinlich die Puffer ausschalten, das macht mich aber nicht froh!
Ein QSocketNotifier kann man nun aber auch fuer Exceptions ansetzen. Weiss zufaellig jemand, was fuer Exceptions von einer seriellen Schnittstelle erzeugt werden und wie man diese auseinanderhalten / behandeln kann ???
Ich denke diese Funktionalitaet gehoert ins Device statt in den Notifier. Ansonsten siehe Doku von Qt und dessen Sourcen... ;-)
Ich habe das mal getestet. TxBuffer-underflow ist keine Exception. Eigentlich auch gut so, denn das ist ja wohl normal! Ich helfe mir jetzt so: Wenn ich die lezten Bytes in den Buffer stelle, gehe ich davon aus, das nichts ihn davon abhalten kann, dass Zeugs zu schicken. In meinem Falle ist das ok, da ich die Steuerleitungen nicht beruecksigtige. Die Zeit, die er zum Senden braucht, addiere ich zum Timeout.
Die Implementierung eine Signals, das aktiviert wird, wenn der Sendepuffer leer ist, kann man so aehnlich machen. Ich stelle mir einen Timer, der sich zur erwarteten Zeit meldet. Dann kann ich nachsehen, ob alles weg ist - wenn ja schicke ich das Signal, wenn nicht stelle ich den Timer neu. Das kann aber ziemlich heftig werden, wenn z.B. nur noch ein Zeichen im Puffer ist und nicht rauskommt ...
Karl-Heinz Fandrey TRW EI Development AMD Saxony Manufacturing GmbH - Fab 30 01109 Dresden, Wilschdorfer Landstrae 101 Phone: +49 351 277 1649 Fax: +49 351 277 5903 E-mail: karl-heinz.fandrey@amd.com