ChibiOS Free Embedded RTOS

Posted: **Fri Feb 07, 2014 1:33 pm**

Hi,

what is the right way to handle serial data with parity e.g. 7E1?
At least the STM32 UART peripherals don't mask out the parity bit of a received character
which means that i see "garbage" at the application level working on the BaseSequentialStream device.
When i do this on linux, the application doesn't see the parity bits. They are either not provided
by the hardware uart or masked out at the driver level.

A possible solution could look like this

Code: Select all

static void serve_interrupt(SerialDriver *sdp) {
  <snip>
  /* Data available.*/
  chSysLockFromIsr();
  while (sr & USART_SR_RXNE) {
    /* Error condition detection.*/
    if (sr & (USART_SR_ORE | USART_SR_NE | USART_SR_FE  | USART_SR_PE))
      set_error(sdp, sr);
    uint16_t c = u->DR;
    /* Mask parity bit according to configuration. */
    switch (u->CR1 & (USART_CR1_PCE | USART_CR1_M))
    {
    case USART_CR1_PCE:
        c &= 0x7f;
        break;
    case USART_CR1_PCE | USART_CR1_M:
        c &= 0xff;
        break;
    default:
        break;
    }
    sdIncomingDataI(sdp, c);
    sr = u->SR;
  }
  chSysUnlockFromIsr();
  <snip>
}

Thanks and cheers,

Vinz

Posted: **Sun Feb 09, 2014 12:09 pm**

Hi,

Good point, after thinking at it for a while my conclusion is that it is better to not break compatibility, somebody could be relying on the behavior.

You may create a subclass of SerialDriver, naming it for example FilteredSerialDriver, and perform the filtering on the high level instead than the ISR. A filtering stream could be an idea too.

Giovanni

Posted: **Tue Feb 11, 2014 2:19 pm**

Some further thoughts:
Adding a higher level driver or stream filter leads to redundant configuration e.g.
the lower level driver has to configure the uart CRs but the higher level driver needs to
know the current frame size and parity settings as well.
Doesn't really look clean to me.
Breakage of compatibility could easily be avoided by adding a preprocessor option.
Also what possible scenario do you have in mind where the parity bit would be required by application
and why then is the behavior on e.g. linux to mask the parity bit?
Remember the uart already checks the parity of incoming data and raises an error if its invalid.

Cheers,

Vinz

Posted: **Tue Feb 11, 2014 2:31 pm**

For example, a while ago I designed a protocol over rs485 where parity errors were used for both detecting errors and detecting start of packets.

Giovanni

ChibiOS Free Embedded RTOS

Serial with parity

Serial with parity

Re: Serial with parity

Re: Serial with parity

Re: Serial with parity