How to get serial error on application layer ?
joel.sherrill at OARcorp.com
Tue Sep 23 21:26:58 UTC 2003
Cedric Aubert wrote:
> --- Ralf Corsepius <corsepiu at faw.uni-ulm.de> wrote:
>>On Tue, 2003-09-23 at 13:34, Cedric Aubert wrote:
>>>I want to known how to have my serial
>>>error from the application layer.
>>>I try to get error from the read() function.
>>>If it's return -1, I should read errno = EIO but
>>>how to known if it's overflow, overrun, framing or
>>>With termios, I don't found any support of this
>>>Does something exist or should I do it myself ?
>>AFAICT, there is no standardized way to do this,
>>because I/O is assumed
>>to "simply work" and "drivers to handle the nasty
>>details" and such
>>errors not to be propagated/exposed to the
>>application level nor to be
> That's exactly what I see, the only think I found is
> the termios IGNPAR and PARMRK to handle parity and
> framing error, but don't supported by the rtems
But those aren't errors, they simply configure the
device driver on what actions to take.
IGNPAR --> Ignore characters with parity errors
PARMRK --> Mark parity errors.
From the GNU C Library manual:
Macro: tcflag_t PARMRK
If this bit is set, input bytes with parity or framing errors are
marked when passed to the program. This bit is meaningful only when
INPCK is set and IGNPAR is not set.
The way erroneous bytes are marked is with two preceding bytes, 377
and 0. Thus, the program actually reads three bytes for one erroneous
byte received from the terminal.
If a valid byte has the value 0377, and ISTRIP (see below) is not
set, the program might confuse it with the prefix that marks a parity
error. So a valid byte 0377 is passed to the program as two bytes, 0377
0377, in this case.
I found what appears to be a fairly detailed discussion of
this on the Linux kernel list.
As best I can tell, tt is largely up to the serial device driver
to do the right thing when it encounters an error. That means it
probably has to know about the IGNPAR and PARMRK bits in its
parity error handler.
>>If you really can't avoid exposing such details to
>>level, you could consider to implement corresponding
>>ioctl's to your
>>However, facing such problems in almost all cases
>>indicate a driver bug.
> Thanks a lot, I will certainly do this
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users