Streaming serial (RS232) data to Linux box / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

Streaming serial (RS232) data to Linux box

Move Thread

LAN_403

WaveRider

Wed May 06 2009, 04:02PM

Registered Member #29 Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500

Hi
I have constructed a PIC based ADC card that spits out 625 samples/second 16-bit data and a 16 bit time-stamp using 115200kb/sec. My question is for anyone who has done serial port programming under Linux.

Everything seems to work well most of the time, but every now and then, a byte is dropped.
The code that does the reading is

/* Read bytes */
        ioctl(fd1, FIONREAD, &bytes); //  Are there any bytes in the serial buffer?
        if(bytes > 0)
        {
           fcntl(fd1, F_SETFL, FNDELAY);
           num_read = read(fd1, buffer, 1024);
           for(i = 0; i < num_read; i++)
           {
              circ_buffer[j_circ] = (unsigned int) buffer[i];
              j_circ = (j_circ + 1) % 1024;

              fprintf(fp, "%u ", (unsigned char)buffer[i]);
              if(!(i_pos % 4)) fprintf(fp, "%d %d %d\n", bytes, num_read, i_pos/4);
              i_pos++;


//                printf("%d %d %u\n" , num_read, j_circ, (unsigned char) buffer[i] );
           }
        }

The code that sets up the port is:

int open_port(char *PortName)
{
    int fd;
    struct termios options;

    fd = open(PortName, O_RDWR | O_NOCTTY | O_NDELAY | O_NONBLOCK);
    if(fd == -1) // Could not open port.
    {
       perror("*** open_port: Unable to open port");
       perror(PortName);
    }
    else
    {
       fcntl(fd, F_SETFL, 0);

       tcgetattr(fd, &options); // Get present terminal options.
       cfsetispeed(&options, B115200);
       cfsetospeed(&options, B115200);

       options.c_cflag |= (CLOCAL | CREAD | CS8); //Set 8N1 local read.

       options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); // Ensure raw bytes
       options.c_oflag &= ~OPOST; // Transmit raw output
       options.c_iflag |= IGNPAR;

       tcsetattr(fd, TCSANOW, &options);
    }
    return(fd);
}

Would I be better off using the unix system call "select" instead of testing with the ioctl call? I know the data coming from the AD card is good and there seem to be no timing or framing issues (standard baud rates are used on both ends). Slowing the sample rate has no effect....the error is still there, so I believe the error is in the PC reading of the data stream... If anyone has an idea, I would be very grateful!!!

Cheers!

Bjørn

Wed May 06 2009, 04:14PM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

How old is the computer and when you slowed down the sample rate did you make sure there was plenty of extra time between every byte sent and not only between each packet?

WaveRider

Wed May 06 2009, 08:20PM

Registered Member #29 Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500

The computer is a pentium 4 from 2004, 3GHz clock rate. I am sending 4 bytes at the standard baud rate in each packet. The stop and start bits are in the correct places and the both the PC and PIC UARTs are standard and sample at the 16x the baud rate (1.8432MHz). I checked all timing on an oscilloscope.

I am convinced that I have not configured the serial read correctly.....perhaps the serial receive buffer is overrunning occasionally...altho' the ioctl call indicates less than 16 bytes on all reads (usual serial buffer size is 16 bytes, I think; I see no more than 8). Anyway, it's my first go at such low-level system programming on Linux.

Carbon_Rod

Thu May 07 2009, 03:37AM

Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155

Remove brlTTY packages and 90% of the serial port problems get solved.

If it is a USB device than such dropped bytes could be a host program not reading/flushing the buffer before it overflows and locks-up or drops. And in some cases the USB devices will inject NULs to keep alive the USB connection.

Also note that USB serial ports auto govern their actual speed (for example setting a 500kbs rs422 device to 384kbs in linux will auto over clock.)

Run this in root to list your port configuration:
sudo setserial -a

note this code tends to work:

Cheers,

Steve Conner

Thu May 07 2009, 10:07AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Windows, Linux etc. are not real-time OS. There's no mechanism to prevent some other process pre-empting the serial driver long enough to let the FIFO overrun, and hence no guarantee that bytes won't be dropped in a streaming scenario. Therefore by Murphy's law, bytes will be dropped now and again, especially at higher baud rates. You should make your protocol tolerant of dropped bytes somehow.

WaveRider

Thu May 07 2009, 11:09AM

Registered Member #29 Joined: Fri Feb 03 2006, 09:00AM
Location: Hasselt, Belgium
Posts: 500

Hi,
Thanks for your responses. CarbonRod: th einterface is a plain-vanilla serial port, no USB. (Actually it is a 4-port PCI serial card I want to use for my data acquisition setup.) Steve: Yes. The protocol is tolerant of some errors, but if can have no errors, that is better.

The good news is: I found the problem. It was indeed in the configuration of the PC port. It was capturing special characters (like LF, CTRL-C, etc...) I used the following initialisation code for a purely raw serial port (how nice that cfmakeraw is a C library function). I let it run for several hours and not a single error occurred.....perfect streaming!

int open_port(char *PortName)
{
    int fd;
    struct termios options;

    fd = open(PortName, O_RDWR | O_NOCTTY | O_NDELAY | O_NONBLOCK);
    if(fd == -1) // Could not open port.
    {
       perror("*** open_port: Unable to open port");
       perror(PortName);
    }
    else
    {
       fcntl(fd, F_SETFL, 0);

       tcgetattr(fd, &options); // Get present terminal options.
       cfsetispeed(&options, B115200); // Set baud rate
       cfsetospeed(&options, B115200);
       cfmakeraw(&options); //set up raw terminal
       tcsetattr(fd, TCSANOW, &options); // Apply attributes
    }
    return(fd);
}

Petezel

Mon Aug 17 2009, 01:07PM

Registered Member #211 Joined: Sun Feb 19 2006, 05:33PM
Location:
Posts: 27

Hi WaveRider and co,
I am glad to see you have reached a solution to the problem, I have to say I am also glad you stirred it up in the first place. My current project calls for me to do some heavy serial communications, likely within a linux environment. Minor differences occur however, where I will be using an FTDI DLP-USB232BM chip to convert serial from my PIC to USB, where virtual com port drivers make an opening to attack it the traditional way. I'm going to look out for what happened with your system and likely watch it with PuTTY.

Cheers folks,
Pete

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob