I did not look as closely at the "Timer and Counter" example as I did at the "Frequency timer" example.
I made a couple very small changes. For one thing I printed the start and ending times.
When I run that I get the following:
Frequency Counter
Took: 489 counts. Frequency: 32719 Hz. Finish: 811 Start: 322
...
Took: 486 counts. Frequency: 32921 Hz. Finish: 1213057881 Start: 1213057395
Took: 486 counts. Frequency: 32921 Hz. Finish: 1221092806 Start: 1221092320
Took: 4294902248 counts. Frequency: 0 Hz. Finish: 1229062193 Start: 1229127241
Took: 486 counts. Frequency: 32921 Hz. Finish: 1237165583 Start: 1237165097
Took: 488 counts. Frequency: 32786 Hz. Finish: 1245200505 Start: 1245200017
It appears that the counter is wrapping. I addressed that by clearing the counter in the "prepareForInterrupts" function.
Another change a made was in the calculation of the frequency. I avoid, as much as possible, floating point numbers. There is conversion overhead and lots of rounding. Of course with integers there can be a lot of truncation, so care must be taken.
uint32_t iElapsedTime = iFinishTime-iStartTime;
uint32_t iFreq = F_CPU / iElapsedTime; // F_CPU = CPU Frequency (i.e. 1600000 for 16 MHz)
lcd.print(iFreq); lcd.print(" Hz. ");
I also used the define so the code works for 16 and 20 Mhz.
When trying to get the maximum accuracy I ran the clock without a prescaler. Since I was measuring the length of the period I wanted to have the time measurement a good as possible.
Again to improve accuracy I increased the sample size. To avoid truncation errors I multiplied the CPU frequency rather than divide the elapsed time. So it came out something like
uint32_t iElapsedTime = iFinishTime-iStartTime;
uint32_t iFreq = (F_CPU * iSampleSize) / iElapsedTime; // F_CPU = CPU Frequency (i.e. 1600000 for 16 MHz)
lcd.print(iFreq); lcd.print(" Hz. ");
I needed to limit the sample size so as to not overflow the 32 bit integer.
I could then play with the sample size. I wanted a large sample without taking too much time so after taking a sample I could look at the elapsed time and if it wasn't too long I could increase my samples.
As I have been writing this I have been monitoring a run and have not seen an example of a time problem, so it must be very rare.
The measuring of time period is probably best suited for lower frequencies.