Unix Programming - serial port: detecting over-runs

Author

serial port: detecting over-runs

Simon Elliott

2005-09-23, 7:00 pm

I've been testing some serial port code. The critical part looks like
this:

while (!found_eof)
{
nbytes = read(fd, buffer_ptr, buffer_size);
if ((nbytes == -1) && (errno != EAGAIN)) // O_NONBLOCK used
{
perror("Error reading from serial port: ");
break;
}
...
delay(N); // delay for N milliseconds
}

I'm sending characters to the port opened as fd, flat out at 115200
bps.

As you'd expect, cranking up the value of N eventually causes
characters to be lost. (On my linux box, the limit is something between
300 and 400 milliseconds.)

However, when characters are lost, no errors are reported. Is there any
way of detecting that an over-run has happened? How does the serial
driver report that its buffers are full?

--
Simon Elliott http://www.ctsn.co.uk

Villy Kruse

2005-09-23, 7:00 pm

On 23 Sep 2005 13:03:54 GMT,
Simon Elliott <> wrote:

>
> However, when characters are lost, no errors are reported. Is there any
> way of detecting that an over-run has happened? How does the serial
> driver report that its buffers are full?
>

It doesn't. Usualy one has to implement a protocol on top of the
serial interface to deal with possible data loss and request for
retransmission. Protocols like uucp and kermit do that to compensate
for unreliable serial data communication.

Usualy the serial driver implements some kind of flow control which the
sender should pay attention to. If the sender do so then the receive
buffer should not overflow.

Villy

Simon Elliott

2005-09-26, 7:00 pm

On 23/09/2005, Villy Kruse wrote:

[color=darkred]
> Usualy the serial driver implements some kind of flow control which
> the sender should pay attention to. If the sender do so then the
> receive buffer should not overflow.

Absolutely. But much the same reasoning applies to parity errors, and
yet the serial driver has ways of notifying the calling application of
parity errors. This led me to wonder whether the driver could also
notify buffer over-runs. Seemingly not!

--
Simon Elliott http://www.ctsn.co.uk

Villy Kruse

2005-09-27, 3:57 am

On 26 Sep 2005 18:16:38 GMT,
Simon Elliott <> wrote:

> On 23/09/2005, Villy Kruse wrote:
>
>
>
> Absolutely. But much the same reasoning applies to parity errors, and
> yet the serial driver has ways of notifying the calling application of
> parity errors. This led me to wonder whether the driver could also
> notify buffer over-runs. Seemingly not!
>

As far as I remember this reporting is done using a special byte sequence,
and overflow may very well be reported in the same way. I've never seen
code depend on this, though, and documentation of this feature I havent
seen for years.

Villy

Simon Elliott

2005-09-28, 6:59 pm

On 27/09/2005, Villy Kruse wrote:

>
> As far as I remember this reporting is done using a special byte
> sequence, and overflow may very well be reported in the same way.
> I've never seen code depend on this, though, and documentation of
> this feature I havent seen for years.

The parity btye sequence is documented in man termios(3):

IGNPAR Ignore framing errors and parity errors.

PARMRK If IGNPAR is not set, prefix a character with a parity error
or framing error with \377 \0. If neither IGNPAR nor PARMRK is set,
read a character with a parity error or framing error as \0.

I wouldn't want to design anything to depend on this, but it's
sometimes useful to know that a parity error has happened.

I can't find any mention of over-run error reporting anywhere.

--
Simon Elliott http://www.ctsn.co.uk

Sponsored Links