COM1 blockierendes Lesen und Schreiben

[digit (Gast)]

Hallo,

wie ich ergoogelt habe, gibt es dazu die Funktion

"SetCommTimeouts"

mit

“COMMTIMEOUTS timeouts;
timeouts.ReadIntervalTimeout = ??
timeouts.ReadTotalTimeoutMultiplier = ??
timeouts.ReadTotalTimeoutConstant = ??
timeouts.WriteTotalTimeoutMultiplier = ??
timeouts.WriteTotalTimeoutConstant = ??
”

wie soll ich sie setzen, damit Lesen und Schreiben blockiert?
Der Hintergrund ist einfach, dass ich ein COM1 Gerät pollen muss
und wenn die Abfragen nicht blockieren, kommt das Gerät nicht mit.

Danke

[Peter (Gast)]

digit schrieb:
> wie soll ich sie setzen, damit Lesen und Schreiben blockiert?
> Der Hintergrund ist einfach, dass ich ein COM1 Gerät pollen muss
> und wenn die Abfragen nicht blockieren, kommt das Gerät nicht mit.

Das Versteht ich nicht, senden blockiert doch bei seriel im normalfall 
immer. Es kann also nur sein das du ein Timeout beim lesen bekommst. 
Aber das hat ja nicht damit zu tun das das gerät nicht hinterher kommt.

Kann es sein das du für das Gerät das Hardware oder Software Handshake 
verwenden musst damit du mitbekommst ob das Gerät bereit ist?

[digit (Gast)]

auf der Gegenseite sitzt ein einfacher MAX232, nur Rx und Tx
werden verwendet. Wenn das PC Programm nun in einer while Schleife
ständig WriteFile aufruft, dann wird doch das Byte auch gesendet?
Ansonsten müsste von irgendwo eine Rückmeldung kommen .. hey
mein Buffer ist voll, Sender warte bitte. Bei I2C ist dieses
letzte Feature in "clock stretching" implementiert. Der UART
kann nichts stretchen, da wird pünktlich in der Bitmitte abgetastet.
Wenn ich so recht überlege, kann es bei UART ohne handshaking
gar kein blockierendes Schreiben geben ...

[Peter (Gast)]

digit schrieb:
> Wenn ich so recht überlege, kann es bei UART ohne handshaking
> gar kein blockierendes Schreiben geben
Doch, die Wartezeit ist aber nur duch die übertragungsrate vorgegeben. 
Es blockiert also so lange bis alle Daten in einem Puffer oder sogar von 
der Schnittstelle gesendet sind. Ob jemand auf die Daten warten ist 
dabei egal. Es blockert also immer gleich lang.

[Purzel H. (hacky)]

Blockierendes UART ? Das ist natuerlich unbrauchbarer Muell. Dafuer gibt 
es ja Treiber, die mit Interrupt arbeiten.

[Peter (Gast)]

A...aha Soooo. schrieb:
> Blockierendes UART ? Das ist natuerlich unbrauchbarer Muell. Dafuer gibt
> es ja Treiber, die mit Interrupt arbeiten.

was hat das denn damit zu tun, der Aufruf kann ja blockieren aber intern 
kann es über den interrupt ablaufen. Wenn ich eh ein Thread habe der 
sich nur um die Schnittstelle kümmernt warum sollte er dann nicht im 
read blockieren?

[Rolf Magnus (Gast)]

digit schrieb:

> Ansonsten müsste von irgendwo eine Rückmeldung kommen .. hey
> mein Buffer ist voll, Sender warte bitte.

Genau das passiert ja, wenn dein Thread blockiert. Die Schnittstelle 
sagt dem System, daß der Puffer voll ist und dieses blockiert daraufhin 
deinen schreibenden Thread, bis wieder Platz ist.

> Wenn ich so recht überlege, kann es bei UART ohne handshaking
> gar kein blockierendes Schreiben geben ...

Doch kann es schon, aber das interessiert sich dann eben nicht dafür, ob 
der Empfänger mitkommt, sondern nur dafür, ob die eigene Schnittstelle 
mitkommt.

> Wenn ich eh ein Thread habe der sich nur um die Schnittstelle kümmernt
> warum sollte er dann nicht im read blockieren?

Man könnte auch umgekehrt fragen: Warum extra einen Thread machen, wenn 
man auch einfach nonblocking arbeiten kann?

[Peter (Gast)]

Rolf Magnus schrieb:
> Man könnte auch umgekehrt fragen: Warum extra einen Thread machen, wenn
> man auch einfach nonblocking arbeiten kann?

wenn man etwas senden und danach auf eine Bestätitung wartet ist es 
wesentlich einfacher wenn das ganze in einem Programm abschnitt erfolgt. 
Wenn jetzt aber die Daten im Interupt ankommen, dann muss ich ja noch 
den Thread informieren das jetzt die Bestätiung der Daten vorliegt die 
er gerade gesendet hat.