Chapter · UART
Timing and trouble
How a receiver reads with no clock wire, what a mismatch looks like, the buffer that can overflow, the faults a receiver can notice, and asking the other side to wait.
- 06Sampling in the middle5 minA UART receiver has no clock wire, so it starts its own timer on the falling edge of the start bit and looks at the line near the middle of each beat. Every start bit sets the timer again, which is why a small difference between the two clocks never builds up past one frame.
- 07When the settings disagree5 minA UART has no clock wire, so the only thing that makes two devices agree is a set of settings each keeps for itself. When they differ, nothing on the line says so. The receiver reads the wrong bits, and the usual evidence is wrong bytes.
- 08The receive buffer4 minA UART receiver does not hand each byte to your program as it arrives. It parks it in a small buffer, first in, first out. If the program reads slower than the bytes come in, the buffer fills, and the bytes that arrive after that are lost, with no resend.
- 09What the line can tell you4 minA UART receiver can notice four things about what it was given, a framing error, a parity error, an overrun and a break. Three say a frame was bad and one says bytes were lost. None of them says why.
- 10Asking the other side to wait5 minA UART receiver cannot ask for a byte to be sent again, but it can ask the sender to wait. Hardware flow control does it with two extra wires, software flow control with two ordinary bytes, and many links use neither.
Start at 06 and read down — the order is the order things get easier in. Or take the one with your part in it; every article stands on its own, and links back to whatever it needs.