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

"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040818.2000.302242snz@pcserv.demon.co.uk...
> On Wednesday, in article <cfv4uf$p6p$1@news.netpower.no>
>      david@no.westcontrol.spam.com "David Brown" wrote:
> >"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
> >news:20040817.1842.302217snz@pcserv.demon.co.uk...
> >> No it is a concept block about forgetting the effects of dividing down
a
> >> faster clock to get a more accurate slower clock.
> >>
> >> Consider the problem of cheap digital clocks/watches that use a
32.768KHz
> >> oscillator, using cheap as possible components but still only drift a
few
> >> seconds a month or even year. This is because the second timing is
> >produced
> >> by dividing down the 32.768KHz by 32768 (15bits) to produce the 1
second
> >> pulse, so the error rate is the oscillator drift * 1/32768 !!
> >>
> >I don't know whether to laugh or cry at this post.  If a 32.768 KHz
crystal
> >is 1% out, then when the signal is divided by 32768 to get a second
pulse,
> >the second pulse will be 1% out.  It's that simple!  It doesn't matter a
>
> When the divisor used is an EXACT match with the prefered divisor then
yes.
> When the divisor used is integer rounded it is not an exact match with
> prefered divisor, and does have an effect on what is going to happen.
>

That's certainly true.  I must admit I've been assuming that exactly
matching divisors have been used throughout this thread.  Being a power of
2, 32768 is convenient to use as a divisor, but it is hardly a requirement -
baud rate divisors are seldom a power of two.  But the value still doesn't
matter (unless you think of a crystal specified in Hz as having an inherrent
+/- 0.5 Hz tolerance).

> If expected divisor is 32890 and only 32768 can be achieved the ratio is
> different due to the combination of the effects, what was missed off
> of the above was "* expected divisor" (due to late night)..
>
> i.e.    expected divisor         1
>       * ---------------- or * -------------- * expected divisor
>         actual divisor        actual divisor
>
> For EXACT matching ratios (e.g. powers of two) this would reduce to '1'
>

If your hardware can't divide by something other than a power of two, then I
would agree.  However, while digital clock manufactorers are looking to save
the smallest fraction of a cent, I don't think a divide by 32890 circuit
would add greatly to the manufacturing costs, so it's not something I
considered relevant.  The emphasis of your post seemed to me that the
relevance of 32.678 KHz was that it needed a relatively small divisor to get
a one-second pulse, and that was what I reacted to.  Certainly other posters
in this thread have thought the size of the divisor to be relevant - if you
don't, then I appologise for assuming you made the same mistake.

> >**** if the crystal is at 32.768 KHz or 9.192631770 GHz (the oscillation
> >frequency of the most common type of atomic clock) - the percentage error
of
> >the source frequency translates directly to the percentage error in the
> >divided frequency.
>
> Both of those examples are exact powers of two, chosen for that precise
> reason.
>

9.192631770 GHz is not a power of two, and was not "chosen" - it comes from
a particular electron transition in cesium ions.  Actually, the ISO
definition of a second is 9192631770 such transition times.

> >The main reason 32.678 kHz crystals are used in watches is because 32.768
> >kHz crystals are used in watches - i.e., the economics of volume make it
> >cheaper to make that particular frequency with high accuracies.  A low
> >frequency was picked because a low frequency means low power.
>
> Also the NOMINAL value of the crystal is an exact power of two.
> No rounding of divisors putting errors in the way, and simpler logic
> required, less logic also means less power.

There is no "rounding" of divisors if the nominal value of the crystal were
an exact multiple of a Hz.  In fact, there is rounding of divisors in
digital watches with 32kHz crystals, since they routinely show hundreths of
a second.  The hundreths are not exact, but the rounding is catered for when
seconds are counted.  In the early days of digital watches, when there were
more discrete components, picking a power of two for the divisor was a good
idea, since the circuitry for a divide-by-power-of-two scaler is easier than
a divide-by-arbitrary-integer scaler, but for modern designs, the difference
is negligble.

>
> >But if logic and physics fail those of you who don't understand timing
> >errors, fall back on experience - the most accurate (in terms of how
> >accuractly it measures time, not how accuractly you happen to have set
it)
> >clock in your room is probably your digital watch, running off a crystal
in
> >the kHz range.
>
> Nominal frequency is exact power of two.
>
> >  The least accurate will be your PC's clock, running off a
> >crystal in the MHz range.
>
> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge
volumes
> with economies of scale to make them cheaply and with high accuracy.
> This frequency is then divided by 12 then divided by 65536, to give an
> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz
interupt
> would require a divisor of 66582.407, more than 16bits of the 8254. This
> feeds interupt and timer software that has loads of kludges in to add part
> seconds every n or x or y seconds, to get nearly right. It was never
designed
> to be a time piece, we all know how deterministic PC software is. The
errors
> come from many parts, so not a valid comparison. Why they did not try to
> achieve 20Hz interupt rates instead still amazes me, as this would have a
> much more accurate timebase clock relative to counters of seconds.
>
> >But the most accurate you have access to will be
> >if you have a GPS receiver, since they get their time from satellites
with
> >atomic clocks running in the GHz range.  Perhaps that will make you
realise
> >that the source rate and the divisor do not matter !
>
> GPS is chosen to be an accurate time piece, otherwise GPS will not work.
> This has to be designed to be an extremely accurate time piece first using
> an exact power of two for the purpose of not introducing rounding errors.
>

You are correct the GPS was designed for and requires a very high accuracy
clock.  The power of two argument is completly wrong, however.  Having an
*integer* divisor is very relevant - part of the (many) inaccuracies in PC
clocks comes from kludges to get non-integer divisors.


> [1] The frequency was chosen for using the clock to drive the output from
a
>     CGA card to a TV using NTSC output. Using it as the clock for the
timing
>     circuit of the system clock was more an afterthought of reducing
numbers
>     of oscillators.
>
> --
> Paul Carpenter | paul@pcserv.demon.co.uk
> <http://www.pcserv.demon.co.uk/>        Main Site
> <http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
> <http://www.badweb.org.uk/>             For those web sites you hate.
>

On Thu, 19 Aug 2004 08:21:45 +0100 (BST), simon@twoplaces.co.uk (Simon
Turner) wrote:

>On Wednesday, in article
>     <20040818.2000.302242snz@pcserv.demon.co.uk>
>     paul$@pcserv.demon.co.uk "Paul Carpenter" wrote:
>
>> Using a cheap 4 * NTSC subcarrier 14.3818MHz crystal[1], made in huge volumes
>> with economies of scale to make them cheaply and with high accuracy.
>> This frequency is then divided by 12 then divided by 65536, to give an
>> approx 18.2Hz interupt rate (actually 18.287..Hz), to achieve 18Hz interupt
>> would require a divisor of 66582.407, more than 16bits of the 8254. This
>> feeds interupt and timer software that has loads of kludges in to add part
>> seconds every n or x or y seconds, to get nearly right. It was never designed
>> to be a time piece, we all know how deterministic PC software is. The errors
>> come from many parts, so not a valid comparison. Why they did not try to
>> achieve 20Hz interupt rates instead still amazes me, as this would have a
>> much more accurate timebase clock relative to counters of seconds.
>
>It has long been suggested that the designers were *trying* to get an
>18.2 Hz clock rate, to make counting hours simple: a 16-bit counter,
>incremented once per cycle at 18.20444444 Hz, rolls over exactly once
>per hour.  It would have been rather neat (for some value of "neat")
>if they had managed it.  (Of course, this may be post-debacle
>revisionism; but it has a ring of plausibility to it.)

If you only need a time of day clock with one second resolution and
the other internal functions do not have to be synchronous to the
change of the last digit in second, those strange interrupt rates
should not be a problem, when the phase accumulator principle is used
as in NCOs (Numerically Controlled Oscillators).

A phase accumulator is set to count for instance microseconds. At each
clock interrupt, the phase accumulator is incremented by the number of
microseconds since the last clock interrupt. In the 18.2..Hz case
54925.4095.... is added at each interrupt. If only integer arithmetic
is available, the value has to be truncated to 54925. When the time
needs to be displayed, the microsecond count is divided by 1000000 and
the quotient gives the seconds and remainder the microseconds (which
grow in about 55 ms steps). 

This clock can be simply calibrated, if an external reference is
available (such as GPS) by calculating the actual crystal frequency.
If the crystal is above nominal, instead add 54924 or even smaller
values to the phase accumulator. If below nominal, add a large number
to the phase accumulator.

Due to trucation/rounding of the added value, the microsecond count
can be as much as 0.5 us off at each interrupt, thus nearly 10 us off
each second or a 10 ppm error,  or about one second off each day. This
is not of a problem in systems, in which needs to be booted many times
each day. 

This time error could be reduced by counting e.g. nanoseconds.

A more severe problem is that the algorithm needs a division
instruction, which might not be available in simple hardware. Instead
of counting microseconds, use a separate 32 bit counter to count
1/2^32 units of time. With the 18.2.. Hz interrupt rate, during each
clock interrupt 235902838 (235902837,62.. rounded up) is added to the
phase accumulator. When this accumulator overflows )i.e. the Carry bit
is set), it is time to update the second count in a separate register.

The cumulative timing error is minimal compared to the typical
frequency errors of the NTSC crystal. No special instructions are
needed, so even with simple 8 bit processors, the clock interrupt only
needs to perform 4 add with carry instructions to update the phase
accumulator and a fifth to update the second count (when the phase
accumulator overflows), of course in addition of the instructions of
loading and storing these values. If high long time accuracy is not
needed, the phase accumulator could be reduced to 24 or 16 bits,
reducing the number of instructions needed in the clock ISR.

With this principle quite strange clock interrupt rates can be used to
count the time of day quite accurately. Since the time is updated only
at each clock interrupt, the displayed TOD can be off by as much as
the clock interrupt rate, in the PC case about 55 ms.

Paul
  

On Thu, 19 Aug 2004 10:27:49 +0200, "David Brown"
<david@no.westcontrol.spam.com> wrote:

> In the early days of digital watches, when there were
>more discrete components, picking a power of two for the divisor was a good
>idea, since the circuitry for a divide-by-power-of-two scaler is easier than
>a divide-by-arbitrary-integer scaler, but for modern designs, the difference
>is negligble.

One reason for picking a power of two is that only the first flip-flop
needs to run at 32768 Hz, the second at 16384 Hz, with only half the
power consumption, the third at 8192 Hz and again halving the power
consumption. 

If the first stages would divide by, say 5, three flip flops (if
synchronous counting is used) and some gates would have to run at the
full clock rate, increasing the total power consumption and reducing
battery life.

Paul