UARTs: required accuracy of the baud rate #14122
Replies: 2 comments 9 replies
-
For me it looks like a good suggestion to tighten the tolerance. As you said, received and sender may be off in opposite directions. We just had the case that even 1% error was too much. |
Beta Was this translation helpful? Give feedback.
-
I just checked the 32F1xx and 32F4xx µC. |
Beta Was this translation helpful? Give feedback.
-
I'd like to make a change to micropython regarding required accuracy of the generated baud rate.
12Mbaud had become standard and is supported by most usb-uarts and other communications systems. The pyboard (of which I have 3) seems to derive its uart clock from 168MHz yielding baud rates from the clock divides below
div Mbaud
2 84
4 42
6 28
8 21
10 16.8
12 14
14 12
If I ask for say 20Mbaud it will set it to 21Mbaud which is exactly 5% deviation from the desired rate.
If I ask for 19Mbaud:
ValueError: set baudrate 21000000 is not within 5% of desired value
I've long heard that uarts can tolerate 5% deviation from the defined baud rate. It basically means that the clocks can drift 1/2 of a bit period over the course of the 10 bits it takes to send an entire frame (start, 8 x payload, stop).
But this is only true if the receive direction has many samples per bit. The actual formula for clock tolerance is
(N-1)//2 / (N*(M-1))
Where N is the number of samples per bit, and M the number of bits per frame. In the receive direction both rising and falling edges of the 168MHz clock sample the Rx line. From the table above
N = 2*div
. And M=10 unless messing with parity, extra stop bits, or 9 bit payload.If we plug 16.8Mbaud into the accuracy formula we find with N=20, M=10 the accuracy requirement is exactly 5%
But with 84Mbaud the accuracy requirement is 2.77% and 42Mbaud: 4.16%
Furthermore we have to halve the tolerance. If the sender is 1% too high, and receiver 1% too low the receiver experiences 2% deviation.
I propose to tighten the tolerance accepted on baud rates to:
(N-1)//2 / (2*N*(M-1))
Note this probably has not caused any issues up to now because uarts faster than 12Mbaud are unusual. In fact the only ones I know about are the pyboard (and STM32FF CPUs) and the uarts I've designed myself in VHDL.
Just wanted to get feedback before I make the change. I wouldn't want my first pull request rejected. Also have to compile for target hardware instead of just the Unix executable.
Beta Was this translation helpful? Give feedback.
All reactions