Simply put, the datasheet for the F12x series suggests as you state, that the UART0 can operate at f.osc/16 and UART1 at f.osc/2.

IIRC, however, that doesn't exactly apply to MODE 0, which was, at the time I inquired with SiLabs, is limited to divide-by-12 and has further limitations on what that can be. The Maxim/Dallas part, however, will allow f.osc/1, subject, of course to the maximum on sysclk, which is only 33 MHz, regardless of how you get there. If the f.osc is multiplied by 4 and the As has been mentioned before, the best way to accomplish many tasks is not necessarily with brute force through the fastest sysclk, but, rather, the correct sysclk, which synchronizes precisely with an externally timed process (by extracting the clock externally and feeding it to the oscillator input) with which you have to interface. Few people care about MODE 0, however. Further, Maxim couldn't tell me the timing relationship between the bit timing and the RI and TI flags, let alone the interrupt itself, so it turns out to be of little use with their part.

Nevertheless, if you want the shortest path to a specific solution, the fastest SYSCLK is not always the solution, as some processes require that the SYSCLK be at a precise frequency or a precise multiple of it. The question then becomes how to get there, and, in fact, whether one can get there at all.

The PLL in the SiLabs part is orders of magnitude to slow in acquisition to be of use in such things, so external hardware has to be used to generate a precisely synchronized system clock. Consider the case in which you have to bit-bang a manchester-encoded data streamfrom each of several input sources. PLL Lock has to be achieved within the "header" else bit framing is not achievable because the SFD (acronym pinched from ethernet) won't be recognized. So, just for the sake of discussion, you have to select a source, acquire precise phase and frequency lock, and then begin to assemble bytes at, say, 2.5 Mbps, which requires sampling at 5 Mbps in quadrature with the incoming data. If your MCU is operating at 4x that rate, you have a pretty good chance of remaining in synchronization with the task so you don't have to check phase and frequency all the time before snagging and incorporating a sample. You have to remain in proper phase and frequency for sampling in order to avoid bit-frame slip, which occurs when the data, generated at one (remotely generated) rate, changes its phase relationship with the local oscillator, and therefore loses its sample window's phase relationship with the incoming data stream. When block sizes are on the order of 40k bits, it's quite likely to happen when crystals are at the commercial standard of 100 ppm.

Now Erik doesn't do this sort of thing often, but I do it all the time. That's why I find this interesting, while Erik does not. That's why I'm acutely aware of the fact that raw 100 MIPS isn't the solution to all problems. Perhaps 66.72E6 or even 33.36E6 might work better, because a loop more easily synchronizes and stays synchronized at that rate.

My point, simply put, was that, while most tasks are easier as one goes faster, raw MIPS, without concern for precise synchronization, isn't the solution to every problem, and as a result, 32 MHz might work better than 42.

This sort of thing comes up all the time if you want to recover data from essentially obsolete mass storage devices, among other things.

RE