ReadFile behaviour on COMs
mike_mccormack at start.com.au
Fri Oct 26 21:29:35 CDT 2001
There is still a number of problems with the COMM code that i am
slowly fixing. They are:
* comm ports opened without FILE_FLAG_OVERLAPPED don't use (any) read
and write timeouts (patch in the works)
* comm timeouts don't work 100% correctly
* WaitCommEvent only works for EV_RXCHAR (difficult to solve
Sounds like your problem might be related to #2. There are a few
special cases for the values in the COMMTIMEOUTS structure that aren't
being dealt with at the moment.
Could you please post a -debugmsg +file,+comm trace and i'll have a
look at it on Monday. Additionally, if the software is available
online somewhere, please post a link to it.
ps. when you say the right byte, you mean the first byte, right?
> somebody showed me an application speaking to a device
> connected to the serial port. The application failed after some >
successfull communication steps. As the protocoll is available
> in some other (open source programm) we could see that the
> program requested two bytes from the device , but ReadFile only
> delivered one byte (with that byte beeing the right one of the
> expected two byte sequence).
> I suspect ReadFile to be the culprit. While the api description
> tells to read all requested bytes ( beside of real errors), our
> implementation happilies returns fewer bytes than requested. In
> the case of COM devices, all timeouts of the SetCommTimeout
> structure should be checked two.
> Anyone with an implementaion for that?
> Uwe Bonnes
mailto:Mike_McCormack at start.com.au
ph +82 16 430 0425
Get your free Australian email account at http://www.Looksmart.com.au
More information about the wine-devel