Serial Raw Mode Errors

QNX Newsgroups (Archives) qdn.public.ddk.input
1

Have serial port configured for raw I/O mode at 19200, N, 8,1.
Communicating with another device. Periodically I get a message that is
missing a character and has a null(0) inserted in the message. The character
missing is after the null. I have captured the serial stream with a serial
analysis tool and the data is actually begin transmitted correctly. In my
reading this sounded like a parity problem but have checked and parity
attribute is not enabled and have also set the ignore parity in the input
flags. Any ideas ?

2

Maury Walters <mwalters@minnetronix.com> wrote:

analysis tool and the data is actually begin transmitted correctly. In my
reading this sounded like a parity problem but have checked and parity
attribute is not enabled and have also set the ignore parity in the input
flags. Any ideas ?

Did you check, if perhaps another programme is accessing the same
serial device?

Something similar happened to me, when I was playing around with my
new driver :slight_smile:

–

| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

3

Maury Walters <mwalters@minnetronix.com> wrote:

Have serial port configured for raw I/O mode at 19200, N, 8,1.
Communicating with another device. Periodically I get a message that is
missing a character and has a null(0) inserted in the message. The character
missing is after the null. I have captured the serial stream with a serial
analysis tool and the data is actually begin transmitted correctly. In my
reading this sounded like a parity problem but have checked and parity
attribute is not enabled and have also set the ignore parity in the input
flags. Any ideas ?

From Advanced Programming in the Unix Environment by W. Richard
Stevens:

In talking about PARMRK:

“If neither IGNPAR nor PARMRK is set, a byte with a framing error
(other than a BREAK) or a byte with a parity error is read as a
single character \0.” This sounds like what you are seeing – though
with parity checking disabled (if you’ve done it at an early
enough level), this would likely be a framing error rather than a
parity error.

You say that the “parity attribute” is not enabled – but actually
there are multiple different “parity” attributes:

PARENB
PARODD
INPCK
IGNPAR
PARMRK

A quick summary, if set…
PARENB – enable hw parity generation & detection
PARODD – use odd or even parity
INPCK – check the result of the parity detection on incoming
IGNPAR – throw away all bytes with bad parity
PARMRK – mark bad parity bytes with \377,\0,X (where X is actual byte)
otherwise bad parity byte read as \0

Also, without parity detection, apparently you can also get something
described as “framing” errors. These don’t seem to have their behaviour
modified by PARENB and INPCK – the handling of them seems to be
controlled at the IGNPAR vs PARMRK level. So, even without parity
errors, you could get framing errors, and get the \0 in your data
stream.

Hope this helps.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

4

Thanks david a couple clarifications please.
If the port parity setting is disabled i.e 19200,n,8,1 does the input
parity
checking(INPCK,IGNPAR,PARMRK<ISTRIP) setup in the input flags still apply?
In other references I was of the understanding that if IGNPAR input flag
was
set that received characters with parity/framing errors are passed through
i.e. the error is ignored.
Is the reference you mentioned by stevens what QNX follows?

thanks maury

David Gibbs wrote in message …

Maury Walters <> mwalters@minnetronix.com> > wrote:
Have serial port configured for raw I/O mode at 19200, N, 8,1.
Communicating with another device. Periodically I get a message that is
missing a character and has a null(0) inserted in the message. The
character
missing is after the null. I have captured the serial stream with a
serial
analysis tool and the data is actually begin transmitted correctly. In
my
reading this sounded like a parity problem but have checked and parity
attribute is not enabled and have also set the ignore parity in the input
flags. Any ideas ?

From Advanced Programming in the Unix Environment by W. Richard
Stevens:

In talking about PARMRK:

“If neither IGNPAR nor PARMRK is set, a byte with a framing error
(other than a BREAK) or a byte with a parity error is read as a
single character \0.” This sounds like what you are seeing – though
with parity checking disabled (if you’ve done it at an early
enough level), this would likely be a framing error rather than a
parity error.

You say that the “parity attribute” is not enabled – but actually
there are multiple different “parity” attributes:

PARENB
PARODD
INPCK
IGNPAR
PARMRK

A quick summary, if set…
PARENB – enable hw parity generation & detection
PARODD – use odd or even parity
INPCK – check the result of the parity detection on incoming
IGNPAR – throw away all bytes with bad parity
PARMRK – mark bad parity bytes with \377,\0,X (where X is actual byte)
otherwise bad parity byte read as \0

Also, without parity detection, apparently you can also get something
described as “framing” errors. These don’t seem to have their behaviour
modified by PARENB and INPCK – the handling of them seems to be
controlled at the IGNPAR vs PARMRK level. So, even without parity
errors, you could get framing errors, and get the \0 in your data
stream.

Hope this helps.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

In email, Maury asked:

: Thanks david a couple clarifications please.
: If the port parity setting is disabled i.e 19200,n,8,1 does the
: input parity checking(INPCK,IGNPAR,PARMRK<ISTRIP) setup in the
: input flags still apply?

To get more details of exactly which bits are set, try “stty -a” on
your port.

If you, for instance do “stty +parenb < /dev/ser1”, then par=none
will become par=odd or par=even.

So, the affect of the flags are, where appropriate, reflected in the
19200,n,8,1.

Or, actually, the setting for parenb and parodd are reflected – they
change the behaviour of the hardware, the rest of the flags change the
behaviour of the software, that is, what it does after getting the
information from the hardware.

: In other references I was of the understanding that if IGNPAR input flag was
: set that received characters with parity/framing errors are passed through
: i.e. the error is ignored.

Hm… I might have been misinterpreting the meaning of “ignore” in
the description of IGNPAR. The description states, “When set, a byte
with a framing error or an input byte with a parity error is ignored.”
Is the byte ignored (doesn’t appear in input stream), or is the
error ignored (byte appears in the input stream with whatever, probably
wrong, value it had).

I’ve just taken a look at the Posix spec, and it says, “If IGNPAR
is set, a byte with a framing or parity error (other than break)
shall be ignored.”

Your other reference seems to suggest the data will be passed
through, but the phrasing of both APUE and the Posix spec
suggests to me that the byte is discarded (ignored) rather than
just the error state being ignored.

: Is the reference you mentioned by stevens what QNX follows?

QNX follows the Posix spec. What Stevens describes generally
matches the Posix spec, and so is generally a good description
of QNX’s behaviour as well. (And, many times, more readable
than the spec.)

But, since you are seeing a \0 byte in the input stream, that
sure suggests that you have -ignpar, -parmrk. (Check with
stty -a as I suggested.) Also, since you have parity checking
disabled, you are probably seeing a framing error.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.