[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    ReadFile behaviour on COMs
From:       Mike McCormack  <mike_mccormack () start ! com ! au>
Date:       2001-10-27 2:29:35
[Download RAW message or body]


Hey Uwe,

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
correctly)

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.

Mike

ps. when you say the right byte, you mean the first byte, right?

> Hallo,
> 
> 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?
> 
> Bye 
> -- 
> Uwe Bonnes



------------------------------------------
mailto:Mike_McCormack@start.com.au
ph +82 16 430 0425

__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au

[prev in list] [next in list] [prev in thread] [next in thread]