Re: Why should I (not) use an internal oscillator for 8-bit micros

From: Neil Bradley (nb_nospam_at_synthcom.com)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 14:58:56 -0700

"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040817.1842.302217snz@pcserv.demon.co.uk...
>>>> Very true. My only point was that everything that comes between the
>>>> start
>>>> and stop bits are susceptible to cumulative error since there is no
>>> (hehehe)
>>>> sync point between data bits.
> All UARTS (or other similar multi-mode devices) that use n-bit start/stop
> byte transfers use a 16 * clock and have done for decades. They could use
> 8 or 4 times clock, but as with everything more accuracy comes from a
> higher
> multiple for sampling frequency. See later.

Sure, effecitvely oversampling/voting as (I think) David had mentioned.

> Once a start bit edge is detected, 8 counts of the clock are used to then
> sample in the middle of the bit to allow for slew and other
> characteristics
> of line transmission as the line could be VERY long or lossy. If the level
> is 0 then a start bit is detected, then 16 clock counts later the first
> bit
> is sampled and so on for the number of bits being sent. After the last
> number
> of expected bits (data and parity) has been received the stop bit is
> sampled
> to make sure it is 1 for the number of stop bit times expected. Failure to
> see stop bit at 1 sets the framing error flag/bit for the device.

The 16550 docs don't internally say how many samples it needs on a given
data bit boundary to consider it one state or the other.

>>But the net effect is still the same even if the internal description
>>isn't
>>right. The lower the baud rate, the worse the cumulative error becomes.
> By using a 16 * clock the cumulative errors is NOT the problem, it is the
> drift of the actual bit rate clock at the receiver compared to the
> transmitter
> as a PERCENTAGE.

The percentage of time per cycle that they're off is constant. But at the
start bit, the two internal UART clocks will drift apart. Call it phase
shift, cumulative error, or whatever, the net effect is the UART samples the
wrong data in the wrong place and eventually gets it wrong.

> Using a 16 * clock means you have more chance of sampling
> at the middle of the bit time for each bit than using a 1 * clock to
> sample.

One would think that to be able to sample semiaccurately that it would need
a 2X clock to sample.

> It is the drift of this sample point that matters with respect to the
> actual transmitted clock rate, NOT the expected clock rate.

Agreed.

> gives you even more benefit of less drift from bit to bit. So cummultaive
> error for a FRAME becomes a function of bit to bit timing as each bit
> width
> can only vary by 1/16 * 1/(master clock divisor) * master clock drift.

Thanks for stating what I have been trying to say all along. ;-)

> For the frame cumulative error to happen the 16 * clock must not drift
> more
> than 1/(n bits) MAXIMUM from the transmitted clock rate. In a 10bit frame
> (8 data, 1 stop, 1 start) which means 1/10 = 10%, to achieve this both end
> must not drift by more than 5% which is the bit rate PERCENTAGE error.

Wouldn't the approach to sampling also have an effect on what percentage of
error was tolerable?

> [snip]

Very nice examples - perfectly understood.

>>No, this is one of those communication things where if I'm not 110% clear,
>>people jump all over me rather than realizing by my descriptions that I
>>really have a clue what I'm talking about but may not be describing it
>>well.
>>My problem is not one of lack of understanding, but rather not being
>>detailed and clear enough in describing everything I'm thinking.
>
> No it is a concept block about forgetting the effects of dividing down a
> faster clock to get a more accurate slower clock.

In the context of at least the sampling, it was a lack of understanding of
how that UART worked. But I'm clear and have been clear on the difference
between synchronous communication and asynchornous communication from day 1,
even if it's lost in translation between what I thought and what I wrote.

>>I actually did develop modem and fax machine firmware for a couple of
>>years,
>>doing async and sync communication, so I really do have relevant
>>experience
>>even if my vernacular isn't 100% to spec.
> Revisit the problem by actually doing the calculations from the oscillator
> downwards for drift and variances like integer rounding of divisors.

The divisor is going to be the bigger impact (agreed) to baud rate problems
than oscillator/clock drift. But I think the original poster said it was
+/-20%, and even changing the clock from 1.84Mhz to 2Mhz is an 8% difference
that I know from experience won't work. However, as you state there's more
to it than that - the sampling mechanism and internal clocking can have a
significant effect on tolerance.

-->Neil

Relevant Pages

  • Re: Why should I (not) use an internal oscillator for 8-bit micros
    ... there is a 16 bit divisor from the input clock. ... multiple for sampling frequency. ... It is the drift of this sample point that matters with respect to the ...
    (comp.arch.embedded)
  • Re: NTP slow to start correction after a drift
    ... The median time for each clock measured over the course of a week has ... I'll try to look into the causes of dispersion later, slow drift ... I am concerned about the length of time it takes before NTP starts ... ntp design. ...
    (comp.protocols.time.ntp)
  • Re: clock problem
    ... and the clock is "only" 3 seconds late now... ... The delay, offset and jitter values are in milliseconds, ... ntpd running, the offset should be reduced slowly. ... clock using the recorded drift. ...
    (freebsd-stable)
  • Re: Isolated Network Drift Problem
    ... best local clock? ... reset drift (delete all their drift files), ... do not start the ntp daemon. ...
    (comp.protocols.time.ntp)
  • Re: Digital processing of analog TV broadcast
    ... FPGA clock - fixed and stable. ... I regenerate the chroma subcarrier using a numerically controlled ... numerically controlled oscillator, and low-pass filter. ... carefully plotting out the sampling components and their aliases. ...
    (sci.electronics.design)