Stop bit, parity and 8N1

A byte does not travel down a UART line alone. It travels inside a frame, which carries its own marks: something at the front to say a byte is starting, and something at the back to put the line right again.

What is in a frame

A frame is, in this order, one start bit (low), the data bits with bit 0 first, an optional parity bit, and one or more stop bits (high). The start bit is the falling edge the receiver wakes on. The stop bit puts the line back at rest, so the next start bit can fall from it.

The setting is written as three characters. 8N1 is eight data bits, no parity, one stop bit: ten beats for one byte, of which eight carry data. 8E1 is eight data bits, even parity, one stop bit, eleven beats. 7O2 is seven data bits, odd parity, two stop bits, also eleven. An ESP32 can run 5 to 8 data bits, none, even or odd parity, and 1, 1.5 or 2 stop bits; the Arduino core offers 1 and 2. 8N1 is what almost everything uses and what begin() assumes if you pass nothing else. A device that wants 7E1 or 8N2 says so in its datasheet.

The stop bit is not the gap

A stop bit is one high beat, or two. It is not the rest between bytes: after it the line may stay high for as long as the sender likes, and there is no minimum. A typical receiver reads only the first stop bit, so the second is just more time before the next start.

Parity

With even parity the sender sets the parity bit so that the number of ones in the data and the parity bit together is even; with odd parity, odd.

Flip one bit on the wire and the count is wrong, so the check fails. Flip two and the count is right again, and the check says nothing while the byte is wrong. So parity catches any odd number of flipped bits and misses every even number. It cannot say which bit, and it cannot correct anything: it is not a checksum. On an ESP32 a frame that fails the check is still delivered to the program, with a flag, and what to do about it is the program's decision.

What it costs when it goes wrong

The two ends must use the same frame. If the sender uses 8E1 and the receiver 8N1, the receiver takes the parity bit for the stop bit, and whenever that bit is low it reports a framing error. If the sender uses 8N1 and the receiver expects parity, it reads the stop bit as its parity bit and reports parity errors on some bytes. Either way the errors look random, which is why this is found late.

Common mistakes

• Assuming 8N1 because the library does. Check the datasheet of the device. A sensor that wants 8E1 gives framing errors at 8N1, even with the baud right.
• Trusting parity to protect the data. It misses every even number of flipped bits, and it only raises a flag. If a wrong byte would hurt, the protocol above the UART needs a real check.
• Setting parity on one end only. Both ends agree on all of it: data bits, parity and stop bits, together with the baud. The ESP32 UART page shows the code side.