This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UART: When to use oversampling?

Hello,

   In the past I've had a high enough SMCLK rate so I just enabled UART oversampling by default. My question: what are the pros/cons of using oversampling on the UART? The datasheet didn't go into much detail on this subject.

 

--Derek

  • The UART (USCI in UART mode) in the MSP430F240 always samples each incoming bit three times and take a majority vote. To over-sample or not to over-sample, that choice is not yours to make.

    There are three alternative clock sources for you to pick, ACLK, SMCLK, or UCLK (external). You should first role out the ones that are not very stable. For each of the available and stable clock source, compare the clock frequency F and the baudrate B you desire. If the ratio F/B is an exact integer, you can generate that baudrate as stable as the clock source without introducing additional bit-time error. If F/B has a fractional part, you may still be able to generate that baudrate with some additional bit-time error. If integer part is 16 or larger, you may have two alternative ways to generate that baudrate (with different additional bit-time errors). You should consider all these possible alternatives and select the one that generates the least bit-time error.

  • The optional 16x oversampling is a new function on the new USCI modules.

    The older USARTs didn't have it.

    The old USARTs did an automatic oversampling and took a majority vote. This implied that the maximum USART bitrate was always lower than what would be possible.

    The new USCIs allow you to decide whether to run without oversampling or use oversampling, depending on the available clock source.
    The 16x oversampling not only gives a majority vote for the bit state, it allows to auto-adjust the state machine to the moment of a bit change (retriggering) based on the current count of the oversampling counter (forward/backward adjustment). So it is possible to do autobaud detection and to better receive data from a source with slightly different timing.

    Oversampling does not, however, influence the precision of the sent data. There only the clock divider and the modulation bits count. But using oversampling in a MSP-to-MSP connection greatly increases stability of the transfer even if both MSPs have different and inprecise clock sources.

    If you have a slow clock source (e.g. a 32kHz crystal), you'll need to switch off oversampling if you want to get more than 1200Bd. But even then, you'll be far off the optimum timing anyway, as such a low clock doesn't allow a precisely enough timing adjustment. See the error tables in the device datasheet/family users guide. Anything above 2% might prevent the other side from understanding your MSP. (taking into account that the other side might be off too and in the opposite direction)

     

  • Jens-Michael Gross said:

    :

    The 16x oversampling not only gives a majority vote for the bit state, it allows to auto-adjust the state machine to the moment of a bit change (retriggering) based on the current count of the oversampling counter (forward/backward adjustment). So it is possible to do autobaud detection and to better receive data from a source with slightly different timing.

    :

     

    How is that forward/backward adjustment working?  Can it also be adjusted 'manually'?

    I'm asking, because I have problems receiving data (with some jitter) with UCOS16=1, while reception with UCOS16=0 seems to work.

    Hardy

  • After re-reading the section in the user manual, it is possible that I mis-interpreted the description of the oversampling and made it smarter than it actually is.
    Using oversampling, however, allows fine-adjusting the baudrate divider more precisely than without by modulating the frequency of each of the 16 sub-bits instead of just the bitrate of a single bit (which is possible in addition). So you can fine-tune the width of each bit instead of just switching the baudrate divider forth and back for each whole bit.
    This is for sending. When receiving, it seems to do just a majority vote 9-of-16 while without oversampling, things are taken as they are when the clock strikes. :)

    The users manual is not very precise about the inner workings (well, it's TIs IP how they actually did it)

    The old USCI modules did a 2of3 vote based on an internally generated 3x sub clock. (at least that's what I remember - I never touched the USART functions for 5 years now, never change a running system)

     

  • Let us take a closer look at “Oversampling Baud Rate Mode” vs. “Low-Frequency Baud Rate Mode” of the UART of the USCI in the MSP430F2xx family -- especially, regarding “sampling”.

    For example, assume that the available clock for BRCLK is 1048576Hz, and the desired Baud Rate is 9600b/s. The ratio 1048576/9600 = 109.2257 allows us to use either of the above mentioned Baud Rate Mode.

    (1) Oversampling Baud Rate Mode. Set UCOS16=1, UCBR=6, and UCBRF=13.
    (2) Low-Frequency Baud Rate Mode. Set UCOS16=0, UCBR=109, and UCBRS=2.

    In order to synchronize with the asynchronous RXD input, the UART receiver samples the RXD to detect the leading edge of the “Start bit”. Both (1) and (2) use the BRCLK to do so. Thus there is no difference in this respect. The sampling rate is 1048576Hz in both cases.

    After the leading edge of the “Start bit” is digitized (or quantized), the UART receiver tries to predict the timing boundary of the “Data bits”, “Parity bit” (if any), and “Stop bits”. Usually, (1) is not as accurate as (2) and in no case (1) is more accurate than (2). In our particular example, (1) has a max error of -2.2% while (2) has a max error of -1.0%.

    Once the timing bondary of those bits are predicted, the UART receiver samples each bit three times and take a majority vote to determine if that bit is 0 or 1. Both (1) and (2) do this. For (1), the three samples are taken near the middle of each bit,  ~1/16 bit-time before, and ~1/16 bit-time after. For (2), the three samples are taken near the middle of each bit, 1/2 BRCLK before, and 1/2 BRCLK after. In our particular example, (1) waits ~6,5usec between samples while (2) waits ~0.48usec between samples.

    My conclusions are that:

    Both (1) and (2) use the BRCLK to sampling RXD to detect the leading edge of “Start-bit”. There is no difference in this regard.

    Both (1) and (2) try to adjust (forward/backward) the timing boundary between the other bits. (2) usually does a better job, but (1) may be good enough.

    Both (1) and (2) take three samples near the middle of all other bits and take a majority vote. The only difference is the periods of time beaten these three samples.

    I think this is consistent with your experience. What is your BRCLK rate, and what Baud Rate are you aiming to generate?

  • old cow yellow said:

    ...I think this is consistent with your experience. What is your BRCLK rate, and what Baud Rate are you aiming to generate?

    Many thanks for the long explanation!

    The BRCLK rate is 460800Hz, Bitrate is 1200Bit/s, so this is perfectly divisible without remainder.

    According to your explanation, this would mean, that the center sample is taken after ~415µs.  For UCOS16=1 the samples around the center sample are ~52µs away, while for UCOS16=0 the time is 2µs.

    With UCOS16=1 data reception shows parity/framing errors, while with UCOS16=0 not.

    Could that mean, that the total jitter on the data stream is somewhere between 300..400µs (150..200µs in both directions)?

    Hardy

**Attention** This is a public forum