0

I am writing a driver for a device that is connected by serial port. Unfortunately, the 9th data bit indicates whether the character should be interpreted as command or as data.

Using the built-in parity check does not work for me because an error is indicated by an additional character (NUL). And then I don't know wheter I received two data bytes or one with an parity error.

Is there a way to get this parity bit elsewhere?

EDIT: Apparently, this problem also exists on Windows (see http://gilzu.com/?p=6). It ended up with rewriting the serial driver. Is this also my only option on Linux?

SecStone
  • 1,733
  • 4
  • 20
  • 31
  • Not posting this as an answer, because I'm not sure if it will help you, but have you considered using `PARMRK`? if so a character with a parity error will be prefixed with `\377 \0`, that is, `0xFF 0x00` – Hasturkun Aug 21 '11 at 11:51
  • @Hasturkun: Thanks for the idea but then I dont know whether I received 0xFF and 0x00 from my device or from the parity checker. – SecStone Aug 21 '11 at 11:58
  • Isn't the parity handled by the UART? AFAIC you can't really get to it, but you can set no parity to get all 8 bits. – Keith Aug 21 '11 at 12:10
  • @SecStone: Don't you have some sort of framing (which would probably resolve where those bytes came from)? also, do you have control over the device? – Hasturkun Aug 21 '11 at 12:12
  • @Keith: AFAIK parity is handled by the UART (as you said). I am looking for a status register (or something similar) where I can get the parity bit of the read characters. – SecStone Aug 21 '11 at 12:18
  • @Hasturkun: Unfortunately I have no control over the device. An additional distinction between data and command frames is also inexistent. – SecStone Aug 21 '11 at 12:58
  • The UART hardware does not retain the parity bit after reception. When parity checking is enabled, the parity calculation is performed by HW. Then the data portion of the received frame is saved using DMA or PIO in memory/RAM. The parity bit is discarded. A parity error status is available/reportable for each received frame if PIO (not DMA) is used by the driver. See https://stackoverflow.com/questions/57193363/stty-serial-port-settings-for-parity-not-persistent/57318783#57318783 – sawdust Feb 19 '22 at 00:57

1 Answers1

0

As I see it, you should be able to use PARMRK as is, assuming that the \377 \0 pattern is unlikely to appear in your input. otherwise, yes, you may modify your serial driver to prepend the parity (or rather, if this byte had a parity error) to each byte. I'd go with the former, though.

Hasturkun
  • 35,395
  • 6
  • 71
  • 104