Baud rate error

What it computes

A classic UART does not generate the baud rate directly. It divides the peripheral clock by an integer to get a sampling clock that runs at 16× (or 8×) the bit rate, then counts 16 samples per bit and reads the middle ones. The divisor has to be an integer, so most clock and baud rate combinations cannot be hit exactly. This is the calculation from any 8250/16550-style datasheet, and from the AVR (ATmega328 datasheet section 19.3), STM32 (RM0008 section 27.3.4) and PIC USART chapters:

divisor = round( f_clk / (oversample × baud) )
actual  = f_clk / (oversample × divisor)
error   = (actual − baud) / baud × 100 %

Register conventions differ. AVR loads UBRR = divisor − 1; 16550 and most PICs load the divisor itself. The tool shows the divisor; subtract one for UBRR. It also checks the divisor against 16 bits, because at low rates on a fast clock it will not fit even when the error is zero.

Usable is defined as |error| ≤ 2 %. That is not a UART specification, it is a budget, and the next section says where it comes from.

Worked example

ATmega328 on the stock 16 MHz crystal, 115200 baud, normal (16×) mode.

ideal   = 16 000 000 / (16 × 115 200) = 8.681
divisor = 9                    (UBRR = 8)
actual  = 16 000 000 / (16 × 9) = 111 111 baud
error   = (111 111 − 115 200) / 115 200 = −3.55 %   → FAIL

The tool gives divisor 9, actual 111111, −3.55 %, FAIL. The AVR datasheet table says the same thing in its "−3.5 %" column. Switch to double-speed (U2X, 8× sampling):

ideal   = 16 000 000 / (8 × 115 200) = 17.36
divisor = 17                   (UBRR = 16)
actual  = 16 000 000 / (8 × 17) = 117 647 baud
error   = +2.12 %              → still FAIL at the 2 % line

The Arduino core uses this U2X setting. It works against a PC because the USB bridge on the far end has almost zero error of its own; against a second 16 MHz AVR at normal speed it is 5.7 % relative and fails.

Now why the budget is about 2 %.

frame     = start + 8 data + stop = 10 bits
receiver  samples at the middle of each bit, resynchronised only at the start edge
drift at the last bit = 10 × error   (error accumulates, no resync mid-frame)
half a bit of margin   = 50 % / 10 = 5 % if the sampler were perfect
16× sampler quantisation costs ~1/16 = 6 % of a bit, majority vote a bit more
practical one-end limit ≈ ±3 %; shared between transmitter and receiver ≈ ±2 % each

So −3.55 % at one end is at the edge even against a perfect partner; add a crystal at ±50 ppm and an RC oscillator at ±1 % and it is gone. That is the whole reason 115200 on a 16 MHz AVR is unreliable, and why 9600 (divisor 104, +0.16 %) never is.

Same rate on a serial-friendly crystal:

11.0592 MHz: 11 059 200 / (16 × 115 200) = 6      exact
 7.3728 MHz:  7 372 800 / (16 × 115 200) = 4      exact
14.7456 MHz: 14 745 600 / (16 × 921 600) = 1      exact, every standard rate below it too

These frequencies are integer multiples of 115200 × 16 = 1.8432 MHz. Pick one of them and the whole table reads 0.00 %.

Where it stops being valid

• Fractional baud rate generators. STM32 USART BRR holds a 12.4 fixed-point divisor (16 fractional steps), so 72 MHz / (16 × 115200) = 39.0625 loads as mantissa 39, fraction 1 and is exact; the integer answer (39, +0.16 %) is the pessimistic case. SAMD has a 16-bit fractional mode, and USB bridges (FT232, CP210x) are under 0.1 % at every common rate. On those parts use the vendor formula; this tool is the worst you could do.
• Clock accuracy is not included. A crystal contributes ±20 to ±100 ppm, negligible. An internal RC oscillator is ±1 % factory calibrated and ±10 % untrimmed. Add it to the figure shown. Auto-baud or a crystal is mandatory for anything above 38400 on an RC clock.
• The two-sided budget. The pass/fail column is one end. Both ends contribute, and their signs add in the worst case. If you control both ends, aim for ±1 % each.

Common mistakes

• Loading the divisor into UBRR without subtracting one. Off by one at divisor 9 is an 11 % error; at divisor 104 it is 1 %, which is why the bug only shows up at high rates.
• Picking 8 MHz or 16 MHz because it makes the millisecond timer neat, then finding 115200 does not work. If the board talks serial as its main job, the crystal should be 11.0592, 14.7456 or 18.432 MHz, and the timer can live with a slightly odd reload value.
• Testing against a PC and concluding the rate is fine. USB bridges have near-zero error and generous receivers; a second MCU with the same −3.5 % in the opposite direction will not talk to it.
• Reading double-speed mode as "better". U2X halves the divisor step so it sometimes lands closer, but the 8× sampler has half the timing margin.
• Ignoring the register width. A 200 MHz peripheral clock at 110 baud needs divisor 113636, which does not fit in 16 bits. The dagger in the table is that case.
• Forgetting the peripheral clock is not the core clock. On STM32 the USARTs sit on APB1 or APB2, which are often divided from SYSCLK. Enter the bus clock, not the PLL output.

Further reading

• ATmega328P datasheet, USART chapter— the UBRR formula and the error tables for common crystals, the source of the −3.5 % figure.
• STM32F1 reference manual RM0008, USART baud rate generation— how the fractional BRR register works and its own error table.
• Maxim tutorial 2141, "Determining clock accuracy requirements for UART communications"— the bit-by-bit drift analysis behind the 2–3 % rule.