# How critical are UART frequencies?

I'm going to be using an 8 MHz crystal to run my microcontroller at 16 MIPS (PLL 4x, 2 cycle instructions.) However, 8 MHz doesn't divide into any UART frequencies AFAIK... so how critical are these frequencies? I plan to use 115,200 baud.

Can UART run within ±1%? If this doesn't work, what frequency should I use? (I would like to get as near to 16 MIPS as possible, for maximum processing speed.) If it matters, I'm using a PIC24FJ64GA004.

If you are within 1%, you should be OK.

Suppose your UART uses a 16x oversampling clock, for example, you can set it to 1,843,200 Hz to 16x oversample 115,200 bps. (oversampling like this is fairly common) This lets the UART count off 8 over-clocks from the falling edge of the start bit, so it can locate the center of the bit cells to within +/- one period of the over clock, after which it counts off 16 periods of the over-clock to determine when to sample data.

If you assume it can hit the center of the start bit, then in order to keep sampling serial data in the correct bit cells across 8 data bits, the clock frequency has to stay between (8-0.5)/8 and (8+0.5)/8, or +/-6.25% of the intended bit rate. Higher overclocking gets closer to the ideal condition of hitting the center of the start bit, but 8x or 16x is usually close enough that you can assume a 5% mismatch will work.

However, you can't count on the other side being perfectly on frequency. If you connect a device that's 4% fast to a device that's 4% slow, you'll have a problem. I've run into at least one case were a PC was running a little slow, and a device a little fast, and the two could only marginally communicate, though the same device was fine with other PCs, and the PC was fine with other devices. (O-scoped these at about 112kbps and 119kbps) For that reason it's good to try to hit the nominal frequency as closely as possible. I've never seen anything within 2% of nominal have a problem.

The usual thing to do is use a master clock rate that provides a whole number multiple of the intended UART over-sampling rate times the baud rate. For example, if you wanted a CPU running at about 8MHz, you might use a 7.3728MHz oscillator, which can be divided by 4 to get 1.8432MHz, which happens to be exactly 16 times 115200.

• 8 MHz could be divided by 69 to get 115,942 which is well within ±1%. I'm wondering if the PIC supports this type of division for its baud rate generator. I'm hoping so, but I don't think it will. Commented Oct 29, 2010 at 22:40
• The PIC has a baud rate generator. It would work well but only for lower baud like 9600, it wouldn't work for high baud like 115,200, it becomes too imprecise. Commented Oct 29, 2010 at 22:44
• Do you think I could use a 7.3728 MHz crystal? (I'm not going to use the internal 7.37 MHz oscillator because I'd like precision.) It allows me to divide by 64 to get a UART frequency of 115,200. It's the fastest I can go with a high tolerance. Commented Oct 29, 2010 at 22:49
• if your UART supports it, it's preferable to give it an overclock (like 16x) so that it can oversample the start bit and find the center of the bit cell, but getting a 16x for 115K to within 1% could be a challenge, unless you use a baud-multiple crystal. Commented Oct 29, 2010 at 22:54

The 1% @JustJeff mentions isn't required. Most UARTs allow for half a bit error on the last bit. Most of the time a frame consists of 1 start bit, 8 databits and 1 stop bit, for a total of 10 bits. Half a bit on 10 bits is 5% (JustJeff's 6.25% doesn't take the start and stop bit in account).

• don't mis-quote me; re "1%", my statement was that this could be difficult to achieve. The "6.25%" was assuming you happened to hit the center of the start bit, and would be the max allowable difference in receiver-vs-transmitter clock rates under such conditions. Commented Jun 12, 2011 at 15:30

One point not yet mentioned is that some devices expect to transmit a byte of data for every byte of data they receive. If such a device is fed data continuously, its baud rate is even 0.1% slower than that of the transmitting device, and it has no facility to send out slightly-shrunken stop bits, its output will will fall a byte behind for every 1000 consecutive bytes that come in. If the device is limited to 16 bytes of buffering, it will drop a byte of data after passing roughly 16,000 and will drop roughly one byte per thousand thereafter. It's worthwhile to note that so-called "1200 baud" modems actually operate at a rate slightly higher than 1200 bits/second (I think it's about 1202) for precisely this reason (so that even if the transmitter is 0.15% faster than it should be, the modem will still pass through all the data).

JustJeff forgot about the start bit, but Stevenh added the stop bit. Assuming the common protocol of 8 data bits, 1 start bit, and no parity bit, (number of stop bits don't matter), there are 8 1/2 bit times from the leading edge of the start bit to the center of the last data bit. Generally, you want the receiver to sample this last bit within 1/4 bit time. Note that 1/2 bit is the guaranteed to fail threshold. Anything near there becomes unrealiable since there is always some electrical noise and jitter.

1/4 divided by 8 1/2 = 2.94%.

As JustJeff mentioned, most UART implementations actually sample the incoming data with a asynchronous 16x clock. That adds another 1/16 bit time uncertainty since that is the error with which the leading edge of the start bit can be measured. 1/16 bit time out of 8 1/2 bits is another .74%. That comes out of the error budget calculated earlier. You end up with 2.2% allowed clock mismatch for the receiver to sample the last bit within 1/4 bit time of its center.

As others have said, using a 7.3728MHz crystal is a common practise when accurate baud rate is required. Usually you can arrange to run the CPU near its maximum rate while hitting the UART baud rate within crystal error.

• I don't agree that stop bits don't matter. In this question communication failed because the stop bit was erroneously set to a low level. Commented Jun 12, 2011 at 14:05
• The stop bit has to be there for overall communication to work, but it doesn't enter into the error budget calculation for most UARTs. UARTs will require some minimum time after the last data bit before the next leading edge of the next start bit. That's what the stop bit time is for. When this time isn't met, you get a "framing error". Perhaps that's sampled like a data bit, but I know of cases where it was handled differently. The old teletypes needed 2 stop bits to give the mechanical mechanism time to be ready to grab the next character. Commented Jun 12, 2011 at 14:22
• I referred to the start bit three times, didn't I? Commented Jun 12, 2011 at 15:24
• @OlinLathrop: The stop bit is required to ensure that when sending a byte whose MSB is zero there will be a falling edge for the next start bit. Different devices behave differently in cases where the data line goes low before it's supposed to, but if there weren't a stop bit a transmitted sequence of zero bytes would contain no useful timing information. Such a requirement could be met via other means with a fixed framing overhead less than 25%, but I'm unaware of anyone doing so. Commented Aug 15, 2013 at 15:42