Mail Archives: cygwin/2005/05/09/17:37:17
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/
- Raw text -