Best way to read character input from serial port (Linux)?

I've got an app that reads characters from a serial port, evaluates these characters and then responds if necessary. I have it working somewhat, but it's not totally reliable. The main issue is that I have a while loop that constantly reads input but I can't figure out how to determine when new characters are sent -- it just reads constantly, sets a variable and outputs it. So, if the master device sends two characters, "0x61, 0x20", My output looks like this:

61
20
20
20
20
20
...and so on forever, since the var that holds the input hasn't been reset.

The bigger issue is that depending on the timing of the while loop, old characters may get mixed up with new input from the master device, which throws everything off. I need the loop to STOP outputting until it knows for sure that new characters are being sent.

Example:

Code:

---

int fd_serialport;
struct termios options;

fd_serialport = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

if(fd_serialport == -1){
        perror("Unable to open /dev/ttyS0");
}

tcgetattr(fd_serialport, &options);
cfsetispeed(&options, B38400);
cfsetospeed(&options, B38400);
options.c_cflag |= (CLOCAL | CREAD);       
options.c_cflag |= PARENB;
options.c_cflag |= PARODD;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
options.c_iflag |= (INPCK | ISTRIP);
tcsetattr(fd_serialport, TCSANOW, &options);
       
fcntl(fd_serialport, F_SETFL, FNDELAY);

while(read(fd_serialport, &data_in[0], sizeof(char))){
               
        printf("%s\n",&data_in[0]);
        usleep(2000);
}

---

Ok, I think I partially figured this out. If I automatically set the variable to '\0' after reading one character, and then add an if statement to check this, it seems to work the way I need it. HOWEVER, there are characters sent that actually are 0 (0x00), that I need to see. If I set the var to '\0' after reading, when input is read that actually is 0 (and valid), these characters are ignored:

Code:

---

while(read(fd_serialport, &data_in[0], sizeof(char))){
               
        if(data_in[0] != '\0'){
                printf("%02x\n",data_in[0]);
        }
        data_in[0] = '\0'; //reset and wait for next char
}

---

Code:

---

while( read( fd_serialport, &data[0], 1 ) != -1 )
{
    ...do stuff...
}

---

You're better off looping until it generates an error, or until you've read some other exit condition. How do you know the serial port isn't going to read the same byte twice, and that it's OK to do so, because that's what's really being sent?


Quzah.

I think I figured it out. I used select() to determine if new data was available (by checking FD_ISSET), then read(). It seems to be working OK.

Another way is to setup the read() to block until new characters are available in the serial input buffer:

Code:

---

fcntl(fd_serialport, F_SETFL, 0);        /* causes read to block until new characters are present */
fcntl(fd_serialport, F_SETFL, FNDELAY);  /* remove this call as it causes read to return immediately */

---

Quote:

---

Originally Posted by itCbitC

Another way is to setup the read() to block until new characters are available in the serial input buffer:

Code:

---

fcntl(fd_serialport, F_SETFL, 0);        /* causes read to block until new characters are present */
fcntl(fd_serialport, F_SETFL, FNDELAY);  /* remove this call as it causes read to return immediately */

---

---

Ah, I see what's going on here. Opening a file descriptor with the O_NONBLOCK flag set won't wait for input before continuing the loop. That's why I had to use select(), which I'm realizing now was unnecessary. Thanks for clearing that up.

I've also discovered the following:

If using non-blocking I/O, you will need to implement your own checks to confirm the completion of reads/writes. I've found a few ways of doing this. One is the way you just mentioned (which seems to be the simplest), using read() with blocking I/O flags set. Second is using a non-blocking file descriptor with select() to check for completed reads. Yet another is using a non-blocking file descriptor flagged with O_ASYNC along with signal(), checking for SIGIO:

Code:

---

fcntl(fd_serialport, F_SETOWN, getpid());
fcntl(fd_serialport, F_SETFL, O_ASYNC);

---

I think I'll just stick with plain old blocking mode. It seems to work reliably.

Quote:

---

Originally Posted by synthetix

Ah, I see what's going on here. Opening a file descriptor with the O_NONBLOCK flag set won't wait for input before continuing the loop. That's why I had to use select(), which I'm realizing now was unnecessary. Thanks for clearing that up.

---

So you took the good solution (select) and replaced it with a dumb one (non-blocking IO).

Quote:

---

Originally Posted by brewbuck

So you took the good solution (select) and replaced it with a dumb one (non-blocking IO).

---

I'm not sure I understand. I don't see the point in using the extra code if using blocking I/O allows me to read the serial port without losing data. If you think I'm overlooking something and making a mistake, please explain.

Using select will allow you to sleep when nothing is waiting to be read.


Quzah.

Quote:

---

Originally Posted by synthetix

I'm not sure I understand. I don't see the point in using the extra code if using blocking I/O allows me to read the serial port without losing data. If you think I'm overlooking something and making a mistake, please explain.

---

How are you going to use non-blocking IO without polling? So what you're saying is, you want to use the entire resources of a multi-gigahertz computer system, completely maxing it out, in order to process data that is coming in at several thousands bytes per second?

From an engineering standpoint you should find that revolting.

Quote:

---

Originally Posted by brewbuck

How are you going to use non-blocking IO without polling? So what you're saying is, you want to use the entire resources of a multi-gigahertz computer system, completely maxing it out, in order to process data that is coming in at several thousands bytes per second?

From an engineering standpoint you should find that revolting.

---

I'm with you, Brewbuck!

If I suggested such a thing on the ~ 300MHz processors that go into our product, I'd be severely told off by whoever reviews the design document (or code if the design document didn't specify it precisely enough).

But of course, if the CPU isn't really doing much, and electricity is for free, then sure, go ahead and burn up those cycles for no use.

--
Mats

Quote:

---

Originally Posted by brewbuck

How are you going to use non-blocking IO without polling? So what you're saying is, you want to use the entire resources of a multi-gigahertz computer system, completely maxing it out, in order to process data that is coming in at several thousands bytes per second?

---

No, I was talking about "blocking I/O" -- that is, NOT setting O_NONBLOCK. I'm not saying it's the best way to do it, I just found that I was getting predictable results reading the serial port this way. Of course, I found NON-BLOCKING I/O without select() or one of the other methods I mentioned a poor way to implement communication with the serial port, as it just looped way too fast to be useful.

I ended up going back to select() as the app grew, since using blocking I/O brings everything to a halt as long as the machine is polling the port.

Couldn't I could use blocking I/O in a thread without select() and still prevent the main thread from stopping dead in its tracks?

If you're not sleeping for some length of time, then you are going to be just check check check check check check check check check check ... as fast as it can, burning up 100% of your CPU time. If one thread is sitting there doing nothing, where the other one is going to say "check check check check...", your scheduler should look and say "Hey, that thread's not doing anything, and this one needs an assload of CPU time, let's let it do its thing..."

Basically, if nothing is pending on either thread, you want to not really do anything at all (assuming you're not actually trying to do anything while you don't have any data), other than sit and wait for something to happen.


Quzah.

The serial port "module" runs in its own thread, using non-blocking I/O (O_NONBLOCK) and select(). I passed a struct to the thread that contains the stuff that the thread needs to update (based on serial input) for the purpose of controlling the main thread:

Code:

---

void                *do_serial_control(void *args); //prototype for ctrl thread

struct SERIALCTRL {
        int        device_status;
        char        timecode[4];
};

struct                SERIALCTRL serial_control;

pthread_create(&thread1, NULL, do_serial_control, (void*)&serial_control);

---

do_serial_control() communicates with the main thread by taking serial port input and updating vars in the main thread via the the struct. These vars are constantly checked in the main loop.

Seems to be working well so far! Thanks for the help!

Curious if you made it non-blocking by setting a timeout in the struct timeval member??