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).
-
If there is no logic implemented handling parity error, it's quite normal that everything goes well even in case of parity mismatch.iFlo– iFlo2024年02月29日 16:01:17 +00:00Commented 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.sawdust– sawdust2024年02月29日 19:20:44 +00:00Commented 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.0andriy– 0andriy2024年03月02日 00:50:06 +00:00Commented Mar 2, 2024 at 0:50
1 Answer 1
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.