RE: Bug in the /dev/ttySx handling code?

["Terry Dabbs" <tdabbs at staktek dot com>]

Perhaps one of the gurus will chime in....

I am not an expert, but I produced the following code that works every day on a number of our production machines, using "com2" to send data out. The comments are what I put at the time, and as far as I know thet describe accurately what is happening. One note: "com_port_name" below is the string "/dev/com2", not "/dev/ttyS1", if that makes a difference.



 /* We now have the name of the com port. The following opens the port for us to use.                                */

rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY );                  /* In case this right after a reboot, windows  */
                                                                     /* may be unstable on the com ports. This is   */
close(rs232_fd);                                                     /* "wake it up" you might say...               */

rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY );                  /* Now for real. "com_port_name" is of the form*/
                                                                     /* "com1", "com2", etc.; "O_RDWR" is open for  */
                                                                     /* read and write. "O_NOCTTY" indicates there  */
                                                                     /* is no controlling terminal (no tty).        */

/* Now we set the parameters using termios functions, these set the port parameters. Mucho importante!              */

tcgetattr(rs232_fd,&my_termios);                              /* Get the current port setup, such as it is.         */
my_termios.c_cflag = B9600 | CS8 | CREAD | CLOCAL | HUPCL;    /* Set the following communication flags:             */
                                                              /* B9600 = 9600 Baud rate.                            */
                                                              /* CS8   = character bits are 8.                      */
                                                              /* CREAD = Enable receiver.                           */
                                                              /* CLOCAL= Ignore modem control lines. No modem here. */
                                                              /* HUPCL = Release/close port when the process dies.  */
my_termios.c_iflag = IXON | IGNBRK | IGNPAR ;                 /* Set the following input flags:                     */
                                                              /* IXON  = Use XON/XOFF flow on output.               */
                                                              /* IGNBRK= Ignore "Break" condition on input.         */
                                                              /* IGNPAR= Ignore framing and parity errors.          */
cfsetospeed(&my_termios,B9600);                               /* Set Speed to 9600 Baud.                            */
tcsetattr(rs232_fd,TCSANOW,&my_termios);                      /* Make the "my_termios" values apply to rs232_fd NOW.*/
tcflush(rs232_fd,TCIOFLUSH);                                  /* Flush any spurious IO data on the port.            */

/* The important opening and set up is done.                                                                        */                                                              
/* Now go read and write. */


Good Luck,

Terry

-----Original Message-----
Subject: 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 fhandler_serial.cc, 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:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/