0

I know 9-bit serial communication is available in Linux using parity bit.

And some Linux version offer MARK/SPACE parity mode, so that i can set parity bit easily.

But as i know, this MARK/SPACE parity mode is not a Linux standard, so a Linux may not support this mode.

How can i check the Linux i am using supports the mode or not ?

Do i have to make some code and test?

I want to know without these additional work.

Any way like by checking configuration information or kernel source?

And, if the Linux doesn't support MARK/SPACE parity mode, is there any way to make it support?

Actually, in ubuntu12.04, it is supported, but when i tried this with ubuntu14.04, it seems not to support when i tested. (in the case of ubuntu14.02 is using lxde in embedded)

==================EDIT=====================

MARK/SPACE parity bit in here means if i can use 9-bit with termios flag CMSPAR.

and how can i check if this flag is available for 9bit communication. and if not, any way to activate this functionality.

otherwise i have to check every byte i send for even and odd parity, and then change parity mode to use 9-bit.

But if i can use CMSPAR flag, i just set PARODD to set parity bit with CMSPAR, regardless of data i send.

And company say the hardware support 9bit.

This is description on MARK/SPACE parity.

SangminKim
  • 8,358
  • 14
  • 69
  • 125
  • First make sure your hardware supports 9 bit serial and mark/space parity. Both of those things are dependent on the UART supporting them. THEN you have to figure out how to tell termios to control them. – Michael Kohne Apr 24 '15 at 14:59
  • @Michael Kohne, that is depending on hardware but kernel ?, because every hardware supporting serial is also supporting parity bit, i think it doesn't depend on hardware, 9-bit is available if i can control parity bit, i think. No? – SangminKim Apr 24 '15 at 15:04
  • 1
    Previous SO question http://stackoverflow.com/questions/3150306/is-it-possible-to-use-9-bit-serial-communication-in-linux – Weather Vane Apr 24 '15 at 18:05
  • Your question is vague. If your serial port hardware supports a 9-bit data frame, then you should state so. If your serial port hardware does not support a 9-bit data frame, then state that you want to *emulate* the 9-bits by using 8 bits and the parity bit. See http://superuser.com/questions/411386/seeking-9-bit-serial-port-card-for-windows-pc/411438#411438 – sawdust Apr 24 '15 at 18:31
  • Protocols like this are invented by companies that also sell the hardware. They know well that you have a very hard time implementing this efficiently, it is only practical on a micro-controller. The kind of processor where it doesn't matter that you can hold-and-catch-fire to check that the fifo is empty. Cold hard fact is that you *must* have the hardware to support it, whether it is off-the-shelf or from the vendor. Drop the vendor if you don't like their attitude. Nobody does. – Hans Passant Apr 24 '15 at 21:53
  • The legitimate argument for 9-bit serial is to have an out-of-band mode or framing bit while permitting 8-bit data, something which is otherwise tricky (I'd personally argue for printable hex encoding in most of those cases). It is true that it is easy with many micros, and tricky to do by abusing a parity bit with a local-bus UART. Where it is going to be really nasty though is if you end up having to do this hack across USB bus latency with an off-the-shelf USB-serial converter. On the flip side, a *custom* USB-serial made out of handy microcontroller eval board can be wonderful at it. – Chris Stratton Nov 13 '15 at 02:25
  • As long as your baud rate is fairly low (~9600) you could probably calculate the necessary parity (even/odd) and force the get the correct value. So for leading byte you'd calculate to ensure parity is always 1, and vice-versa on the data following. – While-E Mar 02 '17 at 15:52

1 Answers1

0

mark parity is the same as sending 2 stopbits (cflag CSTOPB) as stopbits are a logic 1 (negative line voltage) with the same length as a data/parity bit

space parity is a matter of calculating the parity of the byte to send, then selecting the parity method that would result in it being logic 0 before sending it.

addressing (which is the most likely thing this is used for) is therefore best done by having bit 9 set to 0 (rather than 1) to indicate the byte sent is an address (as it takes way more cpu cycles to set it to 0 than to set it to 1 ;) so just use 1 for all the data payload in between, and 0 for the few times you change the addressed unit.

receiving can be done in an always compatible way with linux on any hardware. but it limits the number of possible addresses to the ones that generate a parity error when the 9th bit(=parity bit=first out of 2 stop bits) is logic 0

therefore you can have maximum 128 address (device groups) on the bus if a linux box with standard hardware is also a listener, rather than just sending data.

also see: Is it possible to use 9-bit serial communication in Linux?

CMSPAR for the record, does not seem to be part of any actual standard. (but then again, neither does most of the rest of termios - suprising... after all those years linux still can't do half of the things the actual hardware could do in dos with assembly 30 years ago) and even that is jittery and bugged (requires sync() or O_SYNC to even be handled in an acceptable timeframe, can't set non-standard baudrates, etc). but hey. back to kernel support for your usb 3 coffee cup holder. way more important than rs232 and ethernet.

Community
  • 1
  • 1
HRH Sven Olaf of CyberBunker
  • 139
  • 5