How to get serial error on application layer ?

[Joel Sherrill]

Cedric Aubert wrote:

> --- Ralf Corsepius <corsepiu at faw.uni-ulm.de> wrote:
> 
>>On Tue, 2003-09-23 at 13:34, Cedric Aubert wrote:
>>
>>>Hi
>>>
>>>I want to known how to have my serial
>>
>>communication
>>
>>>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
>>
>>>parity error.
>>>
>>>With termios, I don't found any support of this
>>
>>type
>>
>>>of error.
>>>
>>>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
>>handled there.
> 
> 
> 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
> termios.

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.

http://www.ussg.iu.edu/hypermail/linux/kernel/0303.3/0945.html

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
>>the application
>>level, you could consider to implement corresponding
>>ioctl's to your
>>driver. 
>>
>>However, facing such problems in almost all cases
>>indicate a driver bug.
>>
>>Ralf
> 
> 
> Thanks a lot, I will certainly do this
> 
> Cedric
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com


-- 
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