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.
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).
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.
