[SOLVED] termio buffer size

Quakeboy02 · 10-13-2015, 09:25 AM

I'm trying to send serial data to a device I'm building through a USB to TTL chip. When I had a PL2303HX in the input, things worked fine. I've changed to an MCP2221 and now there seems to be some sort of termio buffer limit of 16 chars. Anything above that and I lose data. I thought that I had the program on the linux side setup to just send raw unbuffered data to the device, but clearly that's not happening. I've been working on this problem for three days straight and I'm stumped. Any help would truly be appreciated.

Here is the termio setup I'm using:

Code:

   memset(&tioPLL,0,sizeof(tioPLL));   /* start with clean tioPLL */
   tioPLL.c_cflag |= (CS8 | CLOCAL | CREAD);  /* 8N1 */
   tioPLL.c_cflag &= ~CSTOPB;  /* 1 stop bit */

   tioPLL.c_iflag &= ~(IXON | IXOFF | IXANY); /*disable software flow control*/
   tioPLL.c_iflag &= ~(INPCK | PARMRK);    /* no parity check*/
   tioPLL.c_iflag |= IGNPAR;     /* ignore parity errors*/

   tioPLL.c_oflag &= ~OPOST;     /* enable raw output */

   tioPLL.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);  /* enable raw input */
   tioPLL.c_cc[VTIME] = 1;

   cfsetospeed(&tioPLL,B57600);     // 9600 baud
   cfsetispeed(&tioPLL,B57600);     // 9600 baud
   tcsetattr(ttyPLL,TCSANOW,&tioPLL);

Here is an idea of how I'm passing data to the device:

Code:

      /* if there's input from STDIN */
      if(FD_ISSET(STDIN_FILENO, &readfs))
      {
         /* if new data is available on the console,
          * send it to the serial port */
         if(read(STDIN_FILENO,&kbdByte,1)>0)
         {
            if(kbdByte != 'q')
            {
               write(STDOUT_FILENO,&kbdByte,1);

               write(ttyPLL,&kbdByte,1);
               if(kbdByte == '\r')
                  write(ttyPLL, "\r\n", 2);
            }
         }
      }

I've just made sure that the PIC using the PL2303HX with the same version of the PIC program (and the same user program on linux) works fine for more than 16 chars of input.

Quakeboy02 · 10-13-2015, 05:00 PM

If it's any help, I've managed to confirm that it has nothing to do with /dev/ttyACM*. I did this by running "gtkterm -p /dev/ttyACM0 -s 57600" and making some trial commands. One thing I don't understand is that I had to use CTL-Enter on gtkterm to send a command through. If that gives anyone any ideas, please give me a hand.

Quakeboy02 · 10-13-2015, 10:51 PM

Apparently something has changed with directing the stdout of a program to a file in going from Squeeze to Jessie. After cutting the program back to just the IO and skipping the redirect, I was getting what I expected. When I redirected stdout on that, I had the same problem. Going back to the original program I see the same thing. Here's what I mean

This works properly:
./testit2 /dev/GPSDO 192.168.1.80

This breaks it, and is the normal way I run the program to get logging.
./testit2 /dev/GPSDO 192.168.1.80 > /home/bob/GPSDOe.logs/junk.log

I'm going to close this problem, though I don't really understand why this happened. I guess I'll have to open a non-blocking output to a log file instead of redirecting stdio.