This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Bug in the /dev/ttySx handling code?

On Mon, May 09, 2005 at 12:46:55PM -0500, Terry Dabbs wrote:
> It appears you are using com1, with this command: 
> stty -F /dev/ttyS0 -a
> But, you strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? 

Yes, I used the right port, as on the Linux PC cat /dev/ttyS0 showed the expected data (after adjusting
the configuration of the port), which was send with my program (eibd) using cygwin.

In the other direction, I did some echo xxxxxxxxxxxxxxxx >/dev/ttyS0. With 9600 baud, I get for such a
request a block of the same byte (I have not checked the hex code).

I am using two PCs, one with Windows, where COM2 is used and a Linux
PC with only one COM port.
stty -F /dev/ttyS0 -a shows the configuration of the Linux PC.

A "mode COMx" in cmd on a unused port shows a baud rate of 9600, so it looks like,
the configuration of the serial port is not changed, although in the current
CVS version of, I can not see any proof for it.

At least, I understand, why stty -F /dev/ttyS0 under cygwin return 0 baud:
tcgetattr returns 0 baud, if DTR is not set, which is different to the behaviour of Linux.

I would like to track the problem down, but as the use of stty (and cat for doing IO) does not
work, I have no idea, how to do it.

mfg Martin Kögler

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]