I have been working with com0com 1.8.0.0 and have encountered an issue. I originally started out doing "synchronous" reads and writes, and everything appeared to be working fine. But in order to make my application more efficient (event driven), I modified my application to use OVERLAPPED I/O (asynchronous). But my WaitForSingleObject calls do not appear to be working when using the com0com ports. I was able to swap the normal COM: ports, and my application worked fine - the I/O operated as expected. But when I try to use CNCB0, the WaitForSingleObject calls hang (I specify a "infinite" timeout, but I suspect if I specified a finite timeout, it would timeout).
I saw that com0com 2.0.0.0 was released, so I installed that. But am encountering the same issue.
Is there some restriction on using OVERLAPPED ReadFile/WriteFile calls with the com0com ports ? Any other flags or configuration needed ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The WaitForSingleObject with "infinite" timeout will hang till operation
completed. So study why that is (can't complete Write because of flow
control, can't Read because of no data to receive, ...).
> Is there some restriction on using OVERLAPPED ReadFile/WriteFile calls with
> the com0com ports ?
There is not any restrictions.
> Any other flags or configuration needed ?
Did you try to enable baud rate emulation and buffer overrun.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was using "infinite" timeout on my read (what I wanted). But it looks like I needed to disable some flow control. Once I did this, the reads started working. What confused me was that I didn't need to do this when I used COM1:.
I had tried baud rate emulation on and off (no affect). But had not adjusted the buffer overrun.
I am good to go. Thank you for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have found a slightly different behaviour concerning WriteFile
see the snippet below
<snip>
bImmediateWrite=WriteFile(....
...
dwRes=WaitForSingleObject(osWrite.hEvent....);
switch (dwRes)
{
case WAIT_OBJECT_0 :
{
if (GetOverlappedResult(hComm,&osWrite, &dwWritten, ...))
}
</snip>
If bImmediateWrite is true the write-completion-event is NOT signalled after the write for a real COM-Port.
In difference on the emulated com port an event is issued.
It is necessary to check bImmediateWrite to avoid GetOverlappedResult in case of immediate write.
Tested with Visual Studio 2005 on a XP Prof - system
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What serial driver you use for a real COM-Port?
On w2k and xp with native serial.sys the write-completion-event
is signalled if bImmediateWrite is true.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm,
IMHO I have nothing special installed on the PC.
Thus it should be the native driver.
Perhaps the problem with my application is also existing on the real COM-port, and it was not encountered because immediate writes are occuring less often than with the emulated COM-port.
Will try to check that next weekend...
Since I have changed the application code to deal with the mentionend behaviour it works now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been working with com0com 1.8.0.0 and have encountered an issue. I originally started out doing "synchronous" reads and writes, and everything appeared to be working fine. But in order to make my application more efficient (event driven), I modified my application to use OVERLAPPED I/O (asynchronous). But my WaitForSingleObject calls do not appear to be working when using the com0com ports. I was able to swap the normal COM: ports, and my application worked fine - the I/O operated as expected. But when I try to use CNCB0, the WaitForSingleObject calls hang (I specify a "infinite" timeout, but I suspect if I specified a finite timeout, it would timeout).
I saw that com0com 2.0.0.0 was released, so I installed that. But am encountering the same issue.
Is there some restriction on using OVERLAPPED ReadFile/WriteFile calls with the com0com ports ? Any other flags or configuration needed ?
The WaitForSingleObject with "infinite" timeout will hang till operation
completed. So study why that is (can't complete Write because of flow
control, can't Read because of no data to receive, ...).
> Is there some restriction on using OVERLAPPED ReadFile/WriteFile calls with
> the com0com ports ?
There is not any restrictions.
> Any other flags or configuration needed ?
Did you try to enable baud rate emulation and buffer overrun.
I was using "infinite" timeout on my read (what I wanted). But it looks like I needed to disable some flow control. Once I did this, the reads started working. What confused me was that I didn't need to do this when I used COM1:.
I had tried baud rate emulation on and off (no affect). But had not adjusted the buffer overrun.
I am good to go. Thank you for your help.
Hello,
I have found a slightly different behaviour concerning WriteFile
see the snippet below
<snip>
bImmediateWrite=WriteFile(....
...
dwRes=WaitForSingleObject(osWrite.hEvent....);
switch (dwRes)
{
case WAIT_OBJECT_0 :
{
if (GetOverlappedResult(hComm,&osWrite, &dwWritten, ...))
}
</snip>
If bImmediateWrite is true the write-completion-event is NOT signalled after the write for a real COM-Port.
In difference on the emulated com port an event is issued.
It is necessary to check bImmediateWrite to avoid GetOverlappedResult in case of immediate write.
Tested with Visual Studio 2005 on a XP Prof - system
What serial driver you use for a real COM-Port?
On w2k and xp with native serial.sys the write-completion-event
is signalled if bImmediateWrite is true.
Hmm,
IMHO I have nothing special installed on the PC.
Thus it should be the native driver.
Perhaps the problem with my application is also existing on the real COM-port, and it was not encountered because immediate writes are occuring less often than with the emulated COM-port.
Will try to check that next weekend...
Since I have changed the application code to deal with the mentionend behaviour it works now.