UART does not support odd parity

[wilusa]

We are building a prototype for a wireless solution using nRF52840 and we found that the UART included in this MCU does not support Odd parity. This is a major handicap that makes me reconsider whether this part is the right choice because the new design supposes to be plug and play with large install base that uses odd parity. I am still in shock and not believing that Nordic Semi made the UART that rigid, which triggers concerns about what other surprises I will be encountering later on. Honestly, I cannot recall any other MCU I have used that is missing this feature.
Is this one of those rare cases where MCU manufacturer has additional registers not exposed to users by default?
Can Nordic confirm that odd parity is not supported?

[Dmitry]

If your devices really check parity bit, I think the only way is to build a "semi-software" TX channel with SPIM peripheral - prepare a bitstream that include start/stop/parity bits and transmit it on MOSI output. It's not very difficult, and frequency generator is the same as in UART (value 0x1d60000 gives 115200 baud). For RX, you can just ignore parity error events.

[wilusa]

Hi Dmitry, thanks for your quick response. I was out of the office for a few days.

We were already considering what you are suggesting. We will try it soon.

[gbenyhe]

Hi Dmitry, thanks for the idea! I had to implement 1200 bps odd parity UART transfer. RX could be done with the UART setting it to even parity and considering parity error as correct parity and vice versa. TX can be done on SPI, but the frequency generator appears not to be the same as in UART, only speeds of 8Mbps divided by different powers of 2 can be set according to my experience. So I did set it to 15625 bps (NRF_SPI0->FREQUENCY=0x00400000UL) and put each bit of the serial data to the buffer 13 times, so the exact speed became 1201,9 bps, which is nice. I did invert the MOSI output by separate hardware as it’s idle state is L while UART TX needs to be H. It might be even nicer to re-clock it using SCLK, as without doing this e.g. the first start bit is a little longer, however I could compensate it by putting only this single bit 11 instead of 13 times to the buffer, and it became accurate enough. Should the length of the resulting bit-stream be bigger than 2040 bits (i.e. 255 bytes) then the transmission must be done in smaller units, as the nrf_drv_spi_transfer() function handles data length as uint8_t. Now the whole thing works fine, thanks again.