Re: (RPI) Changing the tty to an external device and validating functionality
Posted: Sun Aug 25, 2019 6:56 pm
How are you counting bits? 7..0?
While I can't explain the first pair, the others almost look like something configured for 7-bit/mark parity (or 7-bit/odd parity), rather than 8-bit/no parity.
Asynchronous serial (UART) tends to be somewhat forgiving of timing mismatches, since each byte transferred is indicated with start-bit signal, so both ends will be in agreement on the start of the byte. You've then got only 8-bit times of data before stop bits (which would look like 0 bits if a receiver were still sampling the data line).
"Serial Port Complete 2nd Ed" suggests that UART clocks traditionally run 16X the (maximum) bit rate, and the link can have up to 3% clock rate error without data corruption. It also states that data is sent LSB first. Since stop bits are "0", a receiver sampling too slowly would read the stop bit as the final (MSB). A receiver sampling too fast would tend to duplicate the next-to-last bit as the MSB. Neither situation matches your data (if it were supposed to be x80 or x83 and you received x00/x03 I have no idea... as reading the stop bit for bit 7 implies bit 7 was read as bit 6, giving x40/x43; Similarly, duplicating next to last bit, for your data, again would see a 0 bit).
The use of a 16X (or higher) internal clock means the receiver can sample multiple times within a bit time and use the most common result (book says some hardware does this), normally sampling will be done at the middle of the bit time, or 8-internal clocks in (24 clocks after start bit detected, then every 16 clocks until stop bit time). A UART still seeing a 1-bit when it expects to sample a stop-bit (0) should produce a framing error in its status register.
Assuming the sender is accurate 115200bps (ignoring the 16X internal clock difference) a 3% delta means the receiver could be running 111744 to 118656 (115200 +/- 3456) before data corruption is noticed.