Hi everyone,
I'm trying to understand what it means by asynchronous in protocols. I understand that I2C and SPI are synchronous, meaning the receiver knows when to read data based on the clock signal. However, UART is asynchronous. How does recover know when to read data
Could someone explain on what exactly is meant by asynchronous in this context?
Thanks!
Both ends need to be in agreement on the baud rate set. Then, the receiver just need to know
when to start sampling. This process is called synchronization. Or in more analog terms: the baud rate sets the frequency, and then synchronization locks in the phase.
The frequency is "by design" (or needs to be set by user), while the phase needs to be resolved in the hardware during "runtime"
Many protocols
only lock in the phase at the start of a frame. For UART this is done by the start bit. The receiver knows (expects) a certain shape of an UART frame, and its statemachine can then decide when to sample the line. However, the exact implementation details can vary per UART.. for example, you could make a functional UART by sampling exactly in the middle of the (presumed) bit period, however, many UARTs use oversampling with e.g. majority vote.
But because the UART only synchronizes its statemachine at the start bit, any frequency error will accumulate over time and hence there are some tolerances on the frequency errors (of both sides). More sophicated protocols are possible, on of which is UART "auto baud" mechanisms. These include sending a
specific character which allows the start bit duration to be measured, so the UART receiver can "automatically" set up its timer registers accordingly. However, the characteristics of this "auto baud" training requires that the user protocol to include that, which is why I don't think its really used that often..
Note that an UART uses a start bit for each individual character(frame) sent. This lowers the time window at which a correct sync is needed to only 10-10.5 bits or so, and hence, quite a poor oscillator tolerance could (theoretically) be supported. Again, may vary per implementation, though.
However if you look at other asynchronous protocols such as CAN, USB HS or RF comms you'll find much stricter oscillator requirements. Some protocols that need to support sending very large frames also have more techniques to maintain synchronization, such as tricks with line encoding (think differential manchester) or using DLLs, PLLs or timing error detectors (popular for SDR).