Thanks for the responses. Sorry, I thought I had thrown the chip in but I must've deleted that bit before posting. I'll add a bit more info to fill out the picture for you.
I'm running on an ATMega 2560 currently and I'm trying to interface with the 8E1 device via Serial2. The 8E1 device is transmitting small 3-byte packets of data, but I have no way to edit firmware on this device to add additional error detection such as CRC or checksums. The data coming in is slow - one byte every 10ms, with a 20ms gap between packets.
To be clear - while the parity check is something I would like to use to have some form of error detection, however incomplete that may be, I'm more interested in reading the data.
From what I've read in the datasheet for the 2560, this is what (I think) would need to be done for the parity check:
- Set Serial2 to even parity by setting UPM21 = 1 and UPM20 = 0
- As each byte is about to be read out of the buffer, check UPE2 to see whether there is parity
- When sending return data, the parity generator automatically adds the parity bit as long as UPM21 = 1
The confusion for me comes from this line (direct quote) from the datasheet:
"The result of the check is stored in the receive buffer together with the received data and stop bits."
If that's the case, then my immediate thought as to why Serial2.read() wouldn't work is the size of the data in the buffer. Is the extra bit not being handled by the SoftwareSerial library?
This gets to the point of why I was interested in a guide to receiving from a buffer in C - as westftw mentioned, I would likely need to rewrite the libraries to handle this and I would like a better understanding of how to pull from the buffer. I would think anything that pulls an entire byte at a time from the buffer would either not be usable, or only be usable with additional filtering of the other bits in the buffer.
I'm not sure why I had such a hard time finding relevant information about this online; maybe I'm not searching for quite the right keywords or something. It seems like this would be a relatively common implementation.
Anyway, thanks for the help so far and I'll update if I make any sort of breakthrough with it. If I'm completely out of line with my thinking on any of this, please let me know.