UART Receiver Sampling Rate

I've sampled at 8 times on one job and it was OK so there is no rule dictating that 16 is the magic number so sampling higher than this is not a problem in anthing other than handling bigger numbers in hardware. Here's a the 16x counter idea: -

From the falling edge of the start bit you "find" the start-bit's "middle" by counting to 8 then, each count of 16 thereafter you "sample" the UART received data to recreate the byte (or bytes) transmitted. Clearly if you had a 32x counter you'd get a tad more accuracy in determining the centre-point of the bit and counting at a higher rate is going to work but the numbers get bigger and the power consumption rise.

For a very simple UART receiver, it really doesn't matter all that much which way you go.

However, many UART designs need to be both robust and flexible, and that drives the design toward creating a 16x clock (or clock enable) signal.

For robustness, it is advantageous to sample each bit multiple times near the center of the bit and then take a vote among the multiple samples in order to minimize the effects of noise. For example, it's common to take samples at 7/16, 8/16 and 9/16 through the bit and take whichever value appears most often. If you tried to take three adjacent samples at 100 MHz, they're almost guaranteed to have the same value even if they are a glitch, so you want them spaced farther apart.

For flexibility — for example, needing to support many different possible baud rates — you want to have just one parameter that controls the baud rate. If you have several different internal delays that depend on the baud rate (i.e., 1 bit period, 1/2 bit period, 7/16 bit period, etc.), the logic becomes more complex than if you have one state machine that runs at, say, 1/16 the bit period. In that case, all of the different delays scale with the one parameter automatically.