# Difference between UART and USART and the essense of oversampling on STM32F4

USART is an asynchronous transmission whereas UART isn't (unless there's more to it). As shown in the photo below, USART being synchronous doesn't need start and end bits since clock is used to sync the data, whereas, in UART, you do need start and stop bits; for rx and tx to talk, they need to be on the same baud rate so when the tx sends out a start bit, rx receives it right away, yeah?

But in STM32F4, I see they use the term USART but the implementation does seem to have a clock. Is there any specific reason? what am I missing?

Also, is oversampling at the RX mainly done to detect errors? I see it samples 3 bits in the center, and if all of them are the same, there's no error otherwise there is. And you can select the oversampling (8,16) based on your baud rate I guess. What about parity check then?

• you need to read what you wrote – jsotola May 29 '20 at 0:06
• they need to be on the same baud rate so when the tx sends out a start bit, rx receives it right away ... the start bit is always received ... it is the subsequent data bits that get incorrectly detected if the baud rate is mismatched – jsotola May 29 '20 at 0:09
• no two clocks are ever the same. Consider what would happen if you try sampling eight times per byte, exactly one sample per bit, but your transmit and receive clock do not exactly match. That is what oversampling is for. – DKNguyen May 29 '20 at 0:28
• Does this help? electronics.stackexchange.com/questions/207870/… – DKNguyen May 29 '20 at 0:37
• parity has nothing to do with oversampling nor does one stop bit vs two nor does 7 or 9 data bits vs 8...those are popular protocol choices, or were at least... – old_timer May 29 '20 at 3:12

USART is an asynchronous transmission

Nope.

USART is "Universal Synchronous/Asynchronous Receiver/Transmitter", which means the same hardware can support both synchronous and asynchronous communication. For the former it needs clock, so it is implemented in USART periphery but is not used when configured in UART mode.

Also, is oversampling at the RX mainly done to detect errors? I see it samples 3 bits in the center, and if all of them are the same, there's no error otherwise there is.

The oversampling (8/16) is just a fancy way to say that RX line is sampled with higher frequency than the baud rate. The main purpose of oversampling is to increase tolerance to clock deviation.

How the sampled values are used is different at different times. For example to detect start bit a special sequence of 10 samples must be matched. When data bits are received either 3 samples (not "3 bits"!) or just a single sample (if ONEBIT is configured) in the middle are used for noise detection and data recovery.

If not all of the 3 samples are the same it does not automatically mean an error. The majority wins and is used as received bit value. At the same time noise error flag is set and can be verified in your code or used to generate interrupt in some special modes.

The differences between an USART and UART for a specific MCU can be read from the MCU datasheet and reference manual, because they might vary between manufacturer and even between product line from the same manufacturer. The basic difference on STM32F4 is that USART has support for synchronous operation with external clock, to be somewhat compatible with SPI, and it supports hardware flow control. UART only supports basic asynchronous operation.

Oversampling implemented to allow the receiver to find out the leading edge of start bit with enough accuracy to be able to find out when it is time to sample the data bits with enough accuracy. If you only sample at the baud rate without oversampling, and you suddenly detect that start bit edge has happened, you don't know if it happened 0.01 bit times earlier, or 0.99 bit times earlier, so you are not able to know when to sample data bits when they are stable.

With 16x oversampling, you know the start bit edge detection to be accurate to one sixteenth or 6.25% of the bit length and can sample the data bits at their center with no more than 6.25% deviation from the center, assuming the baud rates are identical. So because it can know the ideal sampling time so accurately, it can tolerate more difference if the devices have baud rate differences.