Linux Serial Port Programming (error character) - Linux

This is a discussion on Linux Serial Port Programming (error character) - Linux ; Parity errors on a serial port are read by the application as 0xFF characters.. Any actual 0xFF data comes across as 0xFF-0xFF (2 0xFF's). Seems to be a hole in this that a parity error followed by a righteous 0xFF ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Linux Serial Port Programming (error character)

  1. Linux Serial Port Programming (error character)

    Parity errors on a serial port are read by the application as 0xFF
    characters.. Any actual 0xFF data comes across as 0xFF-0xFF (2 0xFF's).
    Seems to be a hole in this that a parity error followed by a righteous
    0xFF would be misinterpreted as a single 0xFF.. so, is there
    documentation anywhere on how this really works?

    Thanks.

  2. Re: Linux Serial Port Programming (error character)

    Jon Mcleod wrote:
    > Parity errors on a serial port are read by the application as 0xFF
    > characters.. Any actual 0xFF data comes across as 0xFF-0xFF (2 0xFF's).
    > Seems to be a hole in this that a parity error followed by a righteous
    > 0xFF would be misinterpreted as a single 0xFF.. so, is there
    > documentation anywhere on how this really works?


    You'd see three 0xFFs, not only two:

    one for the parity error, two for the righteous 0xFF.

    You won't be able to distinguish a bad character followed by a 0xFF from
    0xFF followed by a bad character, though.

    Josef
    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html

  3. Re: Linux Serial Port Programming (error character)

    Josef Moellers wrote:

    >
    > You'd see three 0xFFs, not only two:
    >
    > one for the parity error, two for the righteous 0xFF.
    >
    > You won't be able to distinguish a bad character followed by a 0xFF from
    > 0xFF followed by a bad character, though.
    >
    > Josef


    Is there some other special condition when a null is involved, eg 0xFF 0x00?

  4. Re: Linux Serial Port Programming (error character)

    Jon Mcleod wrote:
    > Josef Moellers wrote:
    >
    >>
    >> You'd see three 0xFFs, not only two:
    >>
    >> one for the parity error, two for the righteous 0xFF.
    >>
    >> You won't be able to distinguish a bad character followed by a 0xFF
    >> from 0xFF followed by a bad character, though.
    >>
    >> Josef

    >
    > Is there some other special condition when a null is involved, eg 0xFF
    > 0x00?


    Dunno, but don't think so, 'cause that's not special in any way.

    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html

  5. Re: Linux Serial Port Programming (error character)


    Jon Mcleod wrote:

    > Parity errors on a serial port are read by the application as 0xFF
    > characters.. Any actual 0xFF data comes across as 0xFF-0xFF (2 0xFF's).
    > Seems to be a hole in this that a parity error followed by a righteous
    > 0xFF would be misinterpreted as a single 0xFF.. so, is there
    > documentation anywhere on how this really works?


    There's no rational reason to distinguish this. Just treat both cases
    as a parity error.

    Remember, parity checks only have a 50% change of detecting corruption
    anyway, so you can't rely on them. And you can't trust the characters
    around a parity error due to burst noise.

    But in any event, the actual rule is this:

    1) An actual 0xff in the data is reported as 0xff 0xff, so an 0xff
    followed by an 0xff is in fact an 0xff of data.

    2) A parity error is reported as 0xff 0x00 n, where 'n' is the data
    received. So an 0xff followed by a zero is a parity error.

    Quoth SUS:

    "If IGNBRK is set, a break condition detected on input is ignored that
    is, not put on the input queue and therefore not read by any process.
    If IGNBRK is not set and BRKINT is set, the break condition will flush
    the input and output queues, and if the terminal is the controlling
    terminal of a foreground process group, the break condition will
    generate a single SIGINT signal to that foreground process group. If
    neither IGNBRK nor BRKINT is set, a break condition is read as a
    single 0x00, or if PARMRK is set, as 0xff 0x00 0x00.

    If IGNPAR is set, a byte with a framing or parity error (other than
    break) is ignored.

    If PARMRK is set, and IGNPAR is not set, a byte with a framing or
    parity error (other than break) is given to the application as the
    three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag
    preceding each sequence and X is the data of the byte received in
    error. To avoid ambiguity in this case, if ISTRIP is not set, a valid
    byte of 0xff is given to the application as 0xff 0xff. If neither
    PARMRK nor IGNPAR is set, a framing or parity error (other than break)
    is given to the application as a single byte 0x00."

    DS

  6. Re: Linux Serial Port Programming (error character)

    Excellent reference!! Thanks a lot.

    Another question: is it possible to turn this behavior OFF in any way?
    Ie, all parity/framing error information is lost and raw characters are
    returned? (I've got a ton of windows code to port where characters are
    just DMA'ed into block buffers, and CRC's catch problems in the block
    anyway).

  7. Re: Linux Serial Port Programming (error character)

    Jon Mcleod wrote:
    > Excellent reference!! Thanks a lot.
    >
    > Another question: is it possible to turn this behavior OFF in any way?
    > Ie, all parity/framing error information is lost and raw characters are
    > returned? (I've got a ton of windows code to port where characters are
    > just DMA'ed into block buffers, and CRC's catch problems in the block
    > anyway).


    To be more clear, I really want an 0xFF to come through as an 0xFF, not
    a 0xFF 0xFF... Can this be accomplished?

  8. Re: Linux Serial Port Programming (error character)

    On Sep 30, 10:04*am, Jon Mcleod wrote:
    > Jon Mcleod wrote:
    > > Excellent reference!! *Thanks a lot.

    >
    > > Another question: is it possible to turn this behavior OFF in any way?
    > > Ie, all parity/framing error information is lost and raw characters are
    > > returned? *(I've got a ton of windows code to port where characters are
    > > just DMA'ed into block buffers, and CRC's catch problems in the block
    > > anyway).

    >
    > To be more clear, I really want an 0xFF to come through as an 0xFF, not
    > a 0xFF 0xFF... *Can this be accomplished?


    IGNPAR.

    DS

  9. Re: Linux Serial Port Programming (error character)

    David Schwartz writes:

    > Jon Mcleod wrote:
    >
    >> Parity errors on a serial port are read by the application as 0xFF
    >> characters.. Any actual 0xFF data comes across as 0xFF-0xFF (2 0xFF's).
    >> Seems to be a hole in this that a parity error followed by a righteous
    >> 0xFF would be misinterpreted as a single 0xFF.. so, is there
    >> documentation anywhere on how this really works?

    >
    > There's no rational reason to distinguish this. Just treat both cases
    > as a parity error.
    >
    > Remember, parity checks only have a 50% change of detecting corruption
    > anyway, so you can't rely on them.


    How do you figure this?

  10. Re: Linux Serial Port Programming (error character)

    On 2008-10-02, Nate Eldredge wrote:

    >> Remember, parity checks only have a 50% change of detecting
    >> corruption anyway, so you can't rely on them.

    >
    > How do you figure this?


    Assuming we're using 9-bit word lengths (including the parity
    bit) and that all corrupted bit patterns are equally probable:
    there is 1 correct and 511 corrupted bit patterns. Of those
    511 corrupted bit patterns, half will have even parity and half
    will have odd parity. IOW, half of the corrupted words will
    have the "correct" parity and will not be detected.

    --
    Grant Edwards grante Yow! Why are these athletic
    at shoe salesmen following
    visi.com me??

  11. Re: Linux Serial Port Programming (error character)

    On Oct 2, 11:03*am, Grant Edwards wrote:

    > On 2008-10-02, Nate Eldredge wrote:


    > >> Remember, parity checks only have a 50% change of detecting
    > >> corruption anyway, so you can't rely on them.


    > > How do you figure this?


    > Assuming we're using 9-bit word lengths (including the parity
    > bit) and that all corrupted bit patterns are equally probable:
    > there is 1 correct and 511 corrupted bit patterns. *Of those
    > 511 corrupted bit patterns, half will have even parity and half
    > will have odd parity. *IOW, half of the corrupted words will
    > have the "correct" parity and will not be detected.


    The counter-argument would be that single bit errors may be the most
    likely kind of error. While there situations where this is the case,
    in most real-world environments burst noise over several bits is the
    most common.

    DS

  12. Re: Linux Serial Port Programming (error character)

    Grant Edwards writes:

    > On 2008-10-02, Nate Eldredge wrote:
    >
    >>> Remember, parity checks only have a 50% change of detecting
    >>> corruption anyway, so you can't rely on them.

    >>
    >> How do you figure this?

    >
    > Assuming we're using 9-bit word lengths (including the parity
    > bit) and that all corrupted bit patterns are equally probable:
    > there is 1 correct and 511 corrupted bit patterns. Of those
    > 511 corrupted bit patterns, half will have even parity and half
    > will have odd parity. IOW, half of the corrupted words will
    > have the "correct" parity and will not be detected.


    I see. I was thinking of a model where bits are flipped with a small
    probability, independently. In that case an undetectable error
    requires two bits in the same byte to be flipped. This is much less
    likely than a single flipped bit in a byte, which would be detected.
    But of course depending on the situation either model might be more
    appropriate.

  13. Re: Linux Serial Port Programming (error character)

    On 2008-10-02, Nate Eldredge wrote:
    > Grant Edwards writes:
    >
    >> On 2008-10-02, Nate Eldredge wrote:
    >>
    >>>> Remember, parity checks only have a 50% change of detecting
    >>>> corruption anyway, so you can't rely on them.
    >>>
    >>> How do you figure this?

    >>
    >> Assuming we're using 9-bit word lengths (including the parity
    >> bit) and that all corrupted bit patterns are equally probable:
    >> there is 1 correct and 511 corrupted bit patterns. Of those
    >> 511 corrupted bit patterns, half will have even parity and half
    >> will have odd parity. IOW, half of the corrupted words will
    >> have the "correct" parity and will not be detected.

    >
    > I see. I was thinking of a model where bits are flipped with
    > a small probability, independently. In that case an
    > undetectable error requires two bits in the same byte to be
    > flipped. This is much less likely than a single flipped bit
    > in a byte, which would be detected. But of course depending on
    > the situation either model might be more appropriate.


    Well said. Without knowing the error characteristics of the
    communication channel, there's not much useful you can say
    about the value of a particular error detection/correction code
    other than evaluating the overhead it imposes. I'm always
    amused by people who go on and on and on about what hashing
    algorithm is "best" for detecting a ROM failure when they've
    got no statistical information about the failure modes of the
    memory device in question. In fact their arguments often
    appear to assume that the failure patterns in a ROM are the
    same as those in long-distance serial communications using
    modems and analog channels.

    --
    Grant Edwards grante Yow! I'm a GENIUS! I want
    at to dispute sentence
    visi.com structure with SUSAN
    SONTAG!!

+ Reply to Thread