Linux Serial Port Programming (error character)
Jon Mcleod
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.
Josef Moellers
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
Jon Mcleod
>
> 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?
Josef Moellers
Dunno, but don't think so, 'cause that's not special in any way.
David Schwartz
Jon Mcleod wrote:
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
Jon Mcleod
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).
Jon Mcleod
To be more clear, I really want an 0xFF to come through as an 0xFF, not
a 0xFF 0xFF... Can this be accomplished?
David Schwartz
IGNPAR.
DS
Nate Eldredge
> 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?
Grant Edwards
>> 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??
David Schwartz
> On 2008-10-02, Nate Eldredge <n...@vulcan.lan> 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
Nate Eldredge
> On 2008-10-02, Nate Eldredge <na...@vulcan.lan> 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.
Grant Edwards
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!!