Mail Archives: cygwin/2006/05/11/07:43:27
On Wed, May 10, 2006 at 05:14:30PM +0100, Dave Korn wrote:
> On 10 May 2006 14:05, Karel Kulhavy wrote:
>
> > Hello
> >
> > It looks like tcdrain in cygwin doesn't wait until data are transmitted,
> > but just drains the software buffer, and doesn't drain the buffer in the
> > 16550A chip. Can you please confirm that this is really how Cygwin
> > works?
>
> Nope, but I can confirm that this is really how Windows works. Cygwin
> relies on the win32 FlushFileBuffers function; it doesn't contain a
> kernel-mode device driver to manipulate the serial port registers, so this is
> probably as close as we can get.
>
> > I got data corrupted because of this because the data rate was switched
> > before all the old data got transmitted.
> >
> > If it's this case, I suggest to add a note about this exception into
> > http://www.cygwin.com/cygwin-api/std-posix.html
> >
> > Doesn't POSIX say "tcdrain() waits until all output written to the
> > object referred to by fd has been transmitted" (taken from man tcdrain),
> > in which case the aforementioned behaviour would not be POSIX compliant.
>
> Yep, it does. BTW, the opengroup posix spec is more definitive than man
> pages, which are often system- and architecture-specific.
>
> http://www.opengroup.org/onlinepubs/000095399/functions/tcdrain.html
>
> However the meaning of "shall block until all output written to the object
> referred to by fildes is transmitted" doesn't seem very clear to me. If "the
But "the object" should be the same object for tcdrain and setting the
speed. The problem for cygwin is that the drain works in a different
point of the data pipeline than the speed, which is what corrupted my
data.
What POSIX means is I think that if you call drain and then set speed,
the data don't get corrupted.
I don't care if cygwin is posix compliant or not - either write there
that's there's an exception in this case, or implement it if you think
it's easy. If you don't do this, people will unnecessary waste time
discovering that what they were promised is not true.
> object referred to" is "the serial port", then it's fair to say that the data
> has been sent to the serial port; it says nothing about where and/or when the
> serial port sends it on to. I can't see "the object referred to by fildes" as
> meaning the device attached to the cable on the far side of the serial port,
> so arguably it's unspecified what it should do about the on-chip buffers.
> IIRC tcdrain was only implemented a little while ago, and there was some
> discussion of the matter on the list, resulting in the current design
> compromise.
>
> Hmm. It looks like it might be possible to call GetCommProperties and test
> dwCurrentTxQueue to see if it was zero, but I dunno if that'll work properly
> in all cases. The docs for PurgeComm suggest using FlushFileBuffers, which is
> what cygwin does do, and don't suggest any issues in relation to caches.
> Maybe calling WaitCommEvent (..., EV_TXEMPTY, ...) might do what you want. If
> you could do some experimentation and tell us what works, we might even be
> able to improve cygwin's tcdrain functionality.
I calculated a delay for 64-byte buffer (4xmore than typical 16550A/
Winbond que) and put it there and now it works.
CL<
>
> At the very worst, you could just look up the
> GetCommProperties->COMMPROP->dwMaxTxQueue and simply delay for that many
> character times (modulo current baudrate settings and flow control issues)
> before changing the speed.
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today....
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Problem reports: http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -