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

^^^^^^^^^^^^^^ Divide by 16 surely

So it is a divide by 16. Nothing new there that has been the de facto way of doing asynchronous byte transmission/reception using start/stop handshaking for decades.

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.

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.

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. 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.

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

The cummulative error of the clock over a whole start/stop data frame must not be such that when sampling what is thought to be the last bit (STOP), you are actually sampling the parity or last data bit, or conversely sampling what is expected to be parity or last data bit, actually sampling the STOP bit. This is still an error for EACH BIT, unless you expect your clock to drift wildly from bit to bit. To stop drift from bit to bit, the 16 * clock gives you this as a benefit, dividing the master clock down to the 16 * clock 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.

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.

Most people will design for total system drift (of both ends) way under 5% usually 2.5% to give better safety margins and reliable operation.

So if you had a 20MHz master clock divided down to give the 16 * clock for 2400 baud

20,000,000 2400 = ---------- X in this instance is 520.833333 16 * X

So the error is 1/8336 * master clock drift, +/- the difference between

520.833333 and expected divisor of 521, which gives two error factors 1/ 0.032% error in bit rate clock for the receiver (521 divisor) due to integer rounding of divisors 2/ the 1/8336 (0.011996161%) that will be caused by drift in the master clock. Unless your clock drifts MASSIVELY this will NOT be a problem.

The main thing to ensure that you start with a fast clock, and divide it down a lot to give accurate bit time. If you use a lower master clock frequency the percentage error for drift goes up.

For 1.8MHz the calculation is

divisor = 1,800,000 = 46.875 you would use 47 ---------- 16 * 2400

The error in bit rate from a 2% clock deviation is 1/ (16 * 47 ) * 2% which is 0.13298%, so the drift of the oscillator is NEGLIGIBLE in this context.

The difference due to integer rounding of the divisor is more pronounced as 1,800,000 bit rate = --------- = 2393.617 an error of 0.26595% 16 * 47

So at 2% drift the bit rate clock has changed from the 2393.617 to

+2% 1.836MHz giving bit rate of 2441.489 using the same divisor. a 1.7287% total error for the receiver

-2% 1.764MHz giving bit rate of 2345.745 using the same divisor. a 0.040724% total error for the receiver

Both of these errors are WELL below the 1/(n bits) max error for a 10bit frame of 10% for the whole system, or 5% for one end, in fact it is well below the 2.5% IF the other end does not drift too far. If the other end uses the same setup the TOTAL SYSTEM drift is

clock drift bit rate drift +2% 2 * 1.728 % = 3.456% -2% 2 * 0.040724 % = 0.081448%

Neither of these look like they will realistically cause a problem.

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 !!

Revisit the problem by actually doing the calculations from the oscillator downwards for drift and variances like integer rounding of divisors.

--
Paul Carpenter		| paul@pcserv.demon.co.uk
        Main Site
              GNU H8 & mailing list info.
             For those web sites you hate.

synchronous/asynchronous

I

synchronous

ends

I

that.

the

I'm now reas> >>> or I2C should work without problems even if the transmition rate

clock

produced

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

**** 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.

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.

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. The least accurate will be your PC's clock, running off a crystal in the MHz range. 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 !

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.

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'

Both of those examples are exact powers of two, chosen for that precise reason.

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.

Nominal frequency is exact power of two.

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.

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.

[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
        Main Site
              GNU H8 & mailing list info.
             For those web sites you hate.

Probably design laziness, and a "we'll fix it later" mindset.... Given the 8254 hardware, and the Xtal you mention, they could have got to within 2.78ppm of 20Hz, with 59924 divisor, and that is within the trim range of any crystal.

Did they use all 3 8254 channels ? - ISTR one was for refresh, but the next sensible design step would have been to cascade two timers, and cascade-clock using the 20Hz sq wave output, which would have meant even windows could keep good time. ( of course, windows was a long way in the future, and who would ever need more than 640K anyway.... :)

-jg

That was my view from a quick look at calcs and the Tech refs.

The other timer was used programmable Tone generator for the speaker, this I checked just now in some old IBM XT and AT Tech Reference manuals I have. Even then they were worried about getting sound effects to help you type a letter :-^

Even using a 20Hz interupt rate would have made less work for coding and system overhead, and a minor improvement on determinisity. I can remember how often things had to be coded to get around the problems of getting 'normal' multiples of seconds for events reasonably reliably.

--
Paul Carpenter		| paul@pcserv.demon.co.uk
        Main Site
              GNU H8 & mailing list info.
             For those web sites you hate.

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.)

--
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer

a 32.768KHz

few

second

crystal

pulse,

yes.

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 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.

of

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.

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.

it)

in

volumes

interupt

designed

errors

with

realise

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. a

timing

numbers

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

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