Linux Serial Comm Prob

Linux Serial Comm Prob

Post by Eric Mino » Fri, 12 Mar 1999 04:00:00



I am using Linux to do some serial IO on COM1
and am running into a bit of trouble.  I have the
port configured in loopback mode as follows:
pin2 -> pin3  (TD to RD)
pin4 -> pin5  (RTS to CTS)
pin6 -> pin8 -> pin20  (DSR to DCD to DTR)

I use a very basic piece of code to write out one
byte and then read it in, as follows:

/* Open COM1, configure it, write 1 byte, read 1 byte */
int iComFd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
termios oTs;
tcgetattr(iComFd, &oTs);
oTs.c_iflag = 0;
oTs.c_oflag = 0;
oTs.c_cflag = B9600 | CS8 | PARENB | PARODD | CREAD;
// have also tried using CLOCAL and HUPCL to no avail
oTs.c_lflag = 0;
oTs.c_cc[VMIN] = 0;
oTs.c_cc[VTIME] = 10;
tcsetattr(iComFd, TCSANOW, &oTs);

unsigned char szMsg[1] = "";
szMsg[0] = 0xFF;   // Just a random byte
int iBytesSent = write(iComFd, szMsg, 1);
sleep(1);
unsigned char szBlah[1] = "";
int iBytesRead = read(iComFd, szBlah, iBytesSent);
close(iComFd);
/* end of code */

This setup works just fine, with one exception.  It
will not work immediately after I reboot the box.  I
have to unplug my loopback connector, then plug it
back in, in order to be able to read data off the
port.  After I do that I can run the program over and
over and it will behave as expected.  I confirmed with
an oscilloscope that the write call is working and is
sending out a byte, and hence that byte is arriving on
pin #3.  So it is the read that is unable to
recognize the arriving data (in the real program I
first use 'ioctl' to see if any data is ready).

In the production program, it will of course not be
practical to have the user constantly unplugging the
device attached to the COM port.  I was also able to
determine that it is pin #8, data carrier detect, which
is the key pin that is needing to be disconnected.  All
the others can stay connected and it will work just fine.

Any ideas what is causing this problem?  Is there some
function I can call to 'reset' the serial port.  Can I
manually take control of the individual pins and cycle
pin #8.  Thanks.

-Eric


 
 
 

1. Linux Serial Comm Prob

I am using Linux to do some serial IO on COM1
and am running into a bit of trouble.  I have the
port configured in loopback mode as follows:
pin2 -> pin3  (TD to RD)
pin4 -> pin5  (RTS to CTS)
pin6 -> pin8 -> pin20  (DSR to DCD to DTR)

I use a very basic piece of code to write out one
byte and then read it in, as follows:

/* Open COM1, configure it, write 1 byte, read 1 byte */
int iComFd = open("/dev/ttyS0", O_RDWR | O_NOCTTY);
termios oTs;
tcgetattr(iComFd, &oTs);
oTs.c_iflag = 0;
oTs.c_oflag = 0;
oTs.c_cflag = B9600 | CS8 | PARENB | PARODD | CREAD;
// have also tried using CLOCAL and HUPCL to no avail
oTs.c_lflag = 0;
oTs.c_cc[VMIN] = 0;
oTs.c_cc[VTIME] = 10;
tcsetattr(iComFd, TCSANOW, &oTs);

unsigned char szMsg[1] = "";
szMsg[0] = 0xFF;   // Just a random byte
int iBytesSent = write(iComFd, szMsg, 1);
sleep(1);
unsigned char szBlah[1] = "";
int iBytesRead = read(iComFd, szBlah, iBytesSent);
close(iComFd);
/* end of code */

This setup works just fine, with one exception.  It
will not work immediately after I reboot the box.  I
have to unplug my loopback connector, then plug it
back in, in order to be able to read data off the
port.  After I do that I can run the program over and
over and it will behave as expected.  I confirmed with
an oscilloscope that the write call is working and is
sending out a byte, and hence that byte is arriving on
pin #3.  So it is the read that is unable to
recognize the arriving data (in the real program I
first use 'ioctl' to see if any data is ready).

In the production program, it will of course not be
practical to have the user constantly unplugging the
device attached to the COM port.  I was also able to
determine that it is pin #8, data carrier detect, which
is the key pin that is needing to be disconnected.  All
the others can stay connected and it will work just fine.

Any ideas what is causing this problem?  Is there some
function I can call to 'reset' the serial port.  Can I
manually take control of the individual pins and cycle
pin #8.  Thanks.

-Eric

2. SLS install error 0x04 problem

3. Serial comm program for linux?

4. To ARP or not to arp ...

5. probs with System Comm.

6. VxVM, rootdg nad kernel panic

7. Jag Comm - oops, is mount prob

8. X setup--Debian 1.3, SiS 6205 chipset

9. Network Comm Probs

10. Help: Prob with Midnight Comm 3

11. Serial Comm. Toolkit/Library for C/C++

12. Reading directly from serial port at 57.6kB, or good comm package

13. Comm program, serial port access?