AsyncPro ComPort blockierend

[Blamaster]

Hi,

ich habe mal eine kurze Frage. Folgendes "Problem" ich muss Pakete über einen ComPort senden. Momentan setze ich dafür AsyncPro ein. Soweit funktioniert das auch ohne Probleme.

Allerdings muss ich zwischen den Paketen eine feste Mindestwartezeit einhalten. AsynchPro ist wie der Name vermuten lässt allerdings asynchron arbeitend. Wenn ich Daten sende landen Sie in einem Buffer der vom AsyncThread "irgendwann mal" bearbeitet wird.

Ich kann im Hauptprogramm zwar sicherstellen das der Send Befehl des ComPort mit einem Mindestabstand von x ms aufgerufen wird aber um wirklich eine Wartezeit zwischen den Paketen garantieren zu können müsste ich sowas wie ein blockierendes senden haben das erst dann zurückkehrt, wenn die Daten auch wirklich den Sendepuffer verlassen haben bzw besser noch von der Windows API verarbeitet wurden.

Weiß da zufällig jemand ob AsyncPro das in iregendeiner Form unterstützt ?

[yogie]

Hallo,
bin gerade im Dienst, kann also nicht nachschauen.
Ich meine es gibtsowas wie ein Flush, dann wird der Buffer
auf jeden Fall gesendet (FlushOutBuffer)

[samso]

Also wenn es denn blockieren soll, dann kannst Du doch auch mit den ganz normalen FileHandling-Routinen ohne den ganzen Overlapped-Firlefanz arbeiten.
Allerdings kann ich mir nicht vorstellen, dass Du damit zum Ziel kommst. Deine Daten werden an den Treiber übergeben, der übergibt das an den IO-Chip und der hat auch wieder einen Ausgangspuffer von 16..128 Bytes. Ich würde da leise Zweifel anmelden, ob Du die Information "alles ist raus" wirklich zuverlässig bei allen Hardware-Konstellationen bekommst. Da kannst Du eigentlich auch gleich selber anhand der verschickten Datenmenge und der Bitrate ausrechnen, wie lange das senden dauert und wann Du folglich das nächsten Datenpacket schicken musst/kannst.

[Blamaster]

@yogie

Der Tipp klang vielversprechend. Ich habe den FlushOutBuffer gerade mal getestet aber das Verhalten ist ein anderes. So wie es aussieht leert FlushOutBuffer einfach "hart" den Sendepuffer aber nicht durch das sofortige senden der Daten, sondern durch das entfernen aus der Queue. (Nach dem Flush geht das vorher gesendete Paket verloren das ließ sich so über einen API Monitor nachvollziehen)

@samso

Direketer Zugriff über das Filesystem wäre zwar möglich allerdings würde ich den Komfort einer fertigen lib schon schöner finden zumal das blockieren auch nur beim senden gewünscht ist. Beim empfangen sind die asynchronen Fähigkeiten der libs schon wünschenswert.

Ich fürchte auch das eine direkte "alles ist raus" Erkennung eventuell nicht genau erkennbar ist. Ich bin aber aber relativ sicher das wenn die Daten erstmal an die API übergeben wurden auch recht zügig versendet werden. Ich glaube kaum das bei einer ComPort Übertragung die API da zwischen den Bytes großartig lange Pausen macht.

Mir würde bei der blockierenden Sendefunktion schon ausreichen zu wissen das die Daten den Sendepuffer des Threads verlassen haben und an die API weitergegeben wurden.