No announcement yet.

COM, parity, and what exactly happens when parity errors occur

  • Filter
  • Time
  • Show
Clear All
new posts

  • COM, parity, and what exactly happens when parity errors occur

    I have a data stream from an existing product I'm trying to get into my uLCD_32DT via COM0 RX and 4D-UPA as a breakout, it's a little unconventionally formatted which I have no control over. It's 72 byte packets of 9-bit words with single start and stop bits but in reality that's conventional 8-bit data with the occasional byte flagged as special by abusing the parity bit.

    I'm hoping I can use the parity function of the UART to read the 9th bit keeping the 8-bit data synchronised into the buffer [ com_Mode(8, 'E', 1, COM0) ] and since I'm not interested in the 9th bit I plan to just ignore the expected random parity errors. However I'm struggling to get this working and as I can't find exactly what happens when a parity error is detected I'm not sure if the problem is with my understanding of: the Diabalo UART, the data stream I'm looking at, the 4D_UPA or perhaps my wiring. I ran a search and there's almost no mention of parity in the Diabolo Internal Functions sheet beyond enabling it in the UART.

    Does incorrect RX parity just cause the COM_ERROR flag to be set harmlessly but the bytes continue to be read into read into the buffer anyway? Parity isn't specifically mentioned under the com_Error() command's notes. Or is the erroneous byte just dumped out of the buffer meaning my hack is doomed?

    The 4D-UPA is disconnected from the USB lead and the 32DT is powered from the product I'm trying to read so there shouldn't be a clash there though I could try COM1 instead I suppose since it won't be wired to the USB bridge chip. It's 5V TTL data.

    Cheers, James

  • #2
    Follow up: using 4D-UPA as a breakout does interfere with COM0 even when not it's not USB powered, switching to COM1 got the data flowing.

    Whatever Diablo does do with RX parity errors (still no idea) they don't stop the UART processing the erroneous bytes, ignoring the error is default behaviour.


    • #3

      The errors are not ignored rather it sets an error flag for the com_Error function, giving the user option on what to do with incorrect data. As for the hardware, its always best to use other COM ports not linked to the USB serial chip.

      Best Regards,


      • #4
        Thanks, it's useful to know for sure what it does with the information. Luckily there is a CRC bundled into my data so I can easily check the integrity without needing the com_Error flag.