Mail Archives: cygwin/2001/01/12/14:51:44
I have a cygwin application that opens /dev/com2 in binary mode for I/O
to a external device at 115200 bps. I'm
using cygwin 1.1.7 on Windows 2000 SP1. The serial I/O is done using
read() and write() in blocking mode.
If I write commands to the device and read the responses from the main
thread, all is well. But I need to
use separate threads (pthreads) one for writing and one for reading.
When I do this, the first command and response is ok, but the second
response includes more data than it should. In the multi-threaded
version, the read thread is normally
blocked on a read(). Here's the good single threaded output translated
to hex:
write : 01 01 ff 06 5e a5 ff ff 02 00
read: 04 0E 04 0A 01 ff 00
write: 01 01 ff 06 A0 a4 ff ff 00 2E
read: 04 0E 04 0A 01 ff 00
Using the multi-threaded application I get:
write : 01 01 ff 06 5e a5 ff ff 02 00
read: 04 0E 04 0A 01 ff 00
write: 01 01 ff 06 A0 a4 ff ff 00 2E
read: 04 0e 04 0a 01 ff 00 00 00 00 0e 04 0a 01 ff 00
That last read returned 16 bytes rather than 7. The first 7 are valid,
but the other 9 are bogus.
I've tried cygwin1.dll from V1.1.6, and V1.1.5 with the same results.
I've also checked with a serial line analyzer
to make sure that the extra bytes are not being sent on the wire. And I
have experimented with various tcsetaddr() settings
to no avail. The trace data above is output immediately after read()
completes, so a bug in the application code is unlikely.
I have set the serial port attributes as follows to let the read()
complete with less than a full buffer:
serialPortAttributes.c_cc[VTIME] = 0; /* inter-character timer
unused */
serialPortAttributes.c_cc[VMIN] = 1; /* blocking read until at
least 1 char received */
I should also mention that the multi-threaded application works fine on
RedHat Linux.
Any ideas?
Thanks
- Bill Hegardt
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -