Uart baud rate STM32

[AAntu.1781]

Hello. I am using uart to communicate two stm32, with a baud rate set at 19200bps. What is the tolerable error percentage for baud rate so that I don't have communication problems?

[Tesla DeLorean]

I'd probably like to keep it with +/- 3%

[Martin_S]

Sampling point for async serial communication is in the middle of the bit at 50%. For normal 8n1 (1 startbit, 8 databits, 1 stopbit) the stream is synced with the edge of the startbit. So after consecutive 10 bits, sender and receiver should still match the same bitposition in the sampling point. This calculates to 50% / 10 = 5%, where Tx and Rx do no longer match. Furthermore the signal quality (cable length!) is also significant. For short distances and low baudrates (19200bps and up to 5 meters) 3% relative tolerance between both endpoints should be working fine. Always assumed you are working with RS232 transceivers.

[AAntu.1781]

is this a general rule for ST line? or will each microcontroller have a different tolerance?

[waclawek.jan]

This is a general rule for UART as such.

You usually have 10 bits in a frame and the timing must not deviate more than half a bit from start to end, that gives you roughly 5%. Now you need some margin for other influences like rise/fall time, sampling jitter etc.; the 3% is a healthy maximum.

Note, that this assumes one "errorneous" communication side and one perfectly timed (with a crystal oscillator). If both are "errorneus", the margin is half, i.e. +-1.5%.

JW

[Tesla DeLorean]

One should consider implementational detail.

Most specifically the quality of you source clocks, and the division mechanisms to get to the baud rate, and oversampling on the reception side.

As the baud rate becomes higher the error in its setting might become due to the granularity of the clock.

For example look at what rates BBR = N-1, N, and N+1 yield

The simplistic integer divider is not the only way to get a clock divided, alternative implementations can be significantly better and have less error.

For 2 Mbps UART one would want to consider a system clock that is a multiple of 16 or 32 MHz

Also be aware that a UART isn't particularly good a determining error, most people don't use parity, and framing errors only catch really gross errors. Use protocols which have longitudinal checksums/crc, that can resync and retry when errors are detected.