load capacitance of the crystal is 20pF...good rule of thumb for stray capacitance to be 5pF
That sounds about right. What are the stability/tolerance specifications for the crystal? 16 MHz crystals with 50-100ppm specifications are typically cut for 18-20 pF load capacitance. Ones with tighter specifications seem to have lower loads specified, but...
Note that the "stray" capacitance actually includes the capacitance that the ATmega presents to the XTAL pins, so it may vary a little. I have no way of measuring it, and I haven't seen any actual specification for the ATmega capacitance. My experience with other CPUs is that it tends to vary from batch to batch. The oscillator circuitry inside the CPU is not really a tightly controlled oscillator circuit. It's just a couple of transistors whose actual characteristics are not actually measured, controlled, or guaranteed by the manufacturer for each and every batch of chips that they produce.
My rule of thumb: If your capacitance is off by a few pF, the frequency may be affected by a few parts per million.
Putting it another way: If the crystal has a specification of 50 parts per million at 20 pF load anything from 15-30 pF may give a total frequency error of something like 60 parts per million.
I suggest that if your application can't tolerate a CPU frequency error of a few hundred parts per million, you have two options: (See Footnote.)
1. Use an external oscillator designed to be an oscillator rather than depending on the rather loosely controlled characteristics of CPU XTAL pins.
2. Expect to have to fine tune the frequency by selecting capacitors for each circuit that you build so that you can get the required frequency.
Sometimes people design their PC boards with parallel sets of pads for each capacitor. Then, as a part of a rather expensive manufacturing test procedure they start with a value slightly less than the nominal value and put additional capacitors on the order of a few pF until the frequency is "close enough." Note that it's usually not practical to measure the frequency directly since putting an instrument on the crystal will add capacitance and will affect the frequency.
Regards,
Dave
Footnote:Do you have an application that requires your CPU frequency to be accurately known to within a few tens of parts per million?
For example: I am using an Arduino setup to create a 50 kHz output signal using a Timer2 interrupt every 10 uSec. The program is doing other stuff, so the normal millis() interrupt timer is also running.
I measured the period of my nominal 50 kHz square wave with a frequency counter. (Hasn't been calibrated for a while, but I think it's "pretty accurate")
With a "real" Arduino Duemilanove, the average period is something like 19.9995 usec. I have no idea as to what the specification of the crystal is, but I consider a 25 ppm error to be outstandingly close.
With homebrew circuits using parts on hand (50 ppm 20 pF crystal and 22 pF caps) I get almost the same results (19.99912 usec period).
In a Solarbotics Ardweeny with a ceramic resonator, I get a period of something like 20.0077 usec, which is an error of 385 ppm. That's .0385%, and is totally acceptable for my application.
If I look at the square wave (all of the circuits) on a 'scope, I see jitter on the order of a hundred of nanoseconds or so. That's acceptable for my application, but it could be a show-stopper for some.
Some jitter is inevitable for any software-generated signal, but it could be smaller than this if there are no other interrupts being serviced, and it could be a
lot smaller if the signal is generated by counting instructions in a loop and not using a timer interrupt at all.
In this case you (probably) wouldn't be using a high-level language at all, and you almost certainly wouldn't be using any interrupts of any kind.
So: What are your real requirements? How accurate do you need the clock to be for your application?
