0

tl;dr - With parity enabled on both sides of a c++ controller and python client, messages don't seem to actually care to validate and wondering if I am missing something to setup or if I need to manually check every message.

I have been trying to use bit parity to validate messages on a surface level between a Microsemi Smartfusion 2 board using a C++ controller with MSS Uart and a Python Client using Pyserial which seems to just become Win32Serial.

When the controller and the client are both setup None Parity, they work fine as as expected. When both are set up with Odd/Odd or Even/Even they work as expected.

The issue we are having with it is that when the Client and Controller are setup with Even/Odd or Odd/Even they seem to work which goes against what we expect. We are expecting it to give us an error or hang somewhere but instead it just works as expected.

Python connecting and setting bit parity

try:
 self.port = serial.Serial(
 port=self.port_name,
 baudrate=SERIAL_CONSTS.BAUDRATE,
 parity=serial.PARITY_ODD,
 stopbits=serial.STOPBITS_ONE,
 bytesize=serial.EIGHTBITS,
 timeout=SERIAL_CONSTS.DEFAULT_TIMEOUT
 )

C++ connecting and setting bit parity

MSS_UART_init(
 &g_mss_uart0,
 UARTParameters::SerialBaudRate_BPS,
 UARTParameters::SerialIFConfig);

Variables for c++ controller

const uint32_t SerialBaudRate_BPS = 4000000U;
 const uint8_t SerialIFConfig =
 MSS_UART_DATA_8_BITS | MSS_UART_ODD_PARITY | MSS_UART_ONE_STOP_BIT;

We've checked the binary messages coming in and out with parity and can see that when set odd and even, the parity bit is correct when sent and received and the message is executed regardless of what parity the receiver has set.

We did find out that with the parity bit set to none on the client or controller, we would receive an acknowledgement error which we expect because the messages are differently sized (it seems to just drop the parity bit altogether).

asked Feb 29, 2024 at 15:48
3
  • If there is no logic implemented handling parity error, it's quite normal that everything goes well even in case of parity mismatch. Commented Feb 29, 2024 at 16:01
  • A UART frame of 8 data bits plus parity can be problematic for some hardware, and when receiving with DMA. See stackoverflow.com/questions/57193363/… Relying on parity on a modern system (e.g. >9600 baud) is a waste of time. For reliable validation of the data, use a CRC32 checkword on the entire message. Commented Feb 29, 2024 at 19:20
  • @sawdust, instead of validating with weak algo it's better to do two things: 1) enable hardware flow control (it is a must on the speeds >= 9600), 2) enable better protocol, like SLIP or PPP. Commented Mar 2, 2024 at 0:50

1 Answer 1

0

Thanks to the comments on here, I have realized that MSS Uart had a function for MSS_UART_get_rx_status that could be checked for a bit parity error and so errors were reported but didn't do anything else.

answered Mar 4, 2024 at 18:42
Sign up to request clarification or add additional context in comments.

Comments

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.