Accurate Interval Timer for
Updated 5 Jan 2013
updated 5 Jan 2013)
This page made it on Hackaday (here's the
link) and got quite a few comments. Here is a summary of some
of the better comments:
Arlet posted a simple integer math solution for use within the ISR that
accumulates cycles and converts to milliseconds. As he explains,
each interrupt is 19968 cycles and each millisecond is 20000 cycles, so
a += 19968;
if (a >= 20000)
a -= 20000;
performs the conversion.
Mathew, reboots, and lwatcdr all suggested a 20.48 MHz crystal, rather
than the 20 MHz crystal I used. This means a binary divisor will
give an even integer multiple for the number of cycles per
interrupts. For this example, a prescaler of /256 yields a reload
value of 80, which removes the need to muck about with the reload
Alex Rossie provided a link to this earlier Hackaday
entry describing a solution similar to mine for creating a TI
Chronos wristwatch that keeps Martian time.
Martin and WitchDoc suggested setting the prescaler to /1 and using a
reload value of 19999 (actually, 20000). This works if you have a
16-bit timer available.
Daid and hat offered suggestions for improving the stability of the
AVR's crystal oscillator using various temperature compensation ideas.
Tom the Brat suggested counting the numbe of milliseconds (ticks),
multiplying by 1000, then dividing by 78125 to get the number of
seconds for display.
jc and Hack Man recommended an external clock source of greater
accuracy than the AVR's crystal. In particular, Hack Man
suggested the Maxim DS3234 SPI-compatible RTC with integrated crystal.
Julian Skidmore offered an interesting twist on my technique.
Rather than use CTC mode, which resets the timer to 0 on each OCR
match, his technique does a simple calculation within the ISR to
compute the next OCR value in free-run mode, adjusting for the lost
cycles with fractional arithmetic. I'm won't go into the details
here, but strongly suggest you read through his comment in the Hackaday
Odokemon (Danny Chouinard) posted a link to a page on his site where he
a crystal oscillator, temperature sensor, and tiny heater (made
from a couple of resistors), and packed all of this into a tiny
insulated box. The concept is to keep the crystal at a fixed
temperature, which reduces or eliminates frequency variations due to
temperature changes. It is really a clever project and quite well
done. I did not find a mention of it on Hackaday, but it deserves
The bottom line for all of this: There are many different ways to
achieve accurate interval timers with small MCUs like the
ATmega168. Depending on how much freedom you have over crystal
frequency, 8-vs-16-bit timers, use of external timing sources,
environmental controls, and other factors, one or more of the above
suggestions may be well suited for your project.
Many microcontroller projects need an interval timer of some kind,
often for accurate timing of intervals from a few seconds to several
hours or days. MCUs like the ATmega168 have timer/counter
subsystems that can act as interval timers, but using these
timer/counters runs into two snags. First, the MCU's timing
reference, usually a crystal, has built-in tolerance issues.
Second, MCUs such as the ATmega168 use a binary prescaler that does not
permit an even division of common crystal frequencies down to even
multiples of milliseconds.
In order to create an accurate interval timer with such an MCU, you
need to address both of these issues. The following design shows
one method for creating such an interval timer, using C in AVRStudio 4.
I'm basing this design on an ATmega168 with a 20 MHz crystal and
suitable caps connected as a timing reference. The actual
schematic isn't really important; you can find such a design all over
the web. I'm focusing on the firmware design here.
The firmware consists of a simple main() function that sets up Timer1
(16-bit timer/counter) in CTC mode, with an interrupt on OC1A
match. The compare register, OCR1A, is loaded with a value that,
with a prescaler of /256, gives an interrupt approximately 1000 times
On each interrupt, a local msecs counter is incremented. The
then checked; if it has hit 1000, it is immediately zeroed and a global
seconds counter is decremented if that counter is not yet zero.
This design creates a down-counting timer that starts at some initial
value and counts down once per second until it hits zero, where it
stays until written with another value.
The difficulty lies with the reload value stored in OCR1A and the
associated prescaler. There is no combination of prescalers and
reload value that provides an accurate one millisecond interval.
(Edit 5 Jan 2013: As pointed
out by Martin and WitchDoc above, this is, stictly speaking, not
true. I should have said that such combination does not exist for
8-bit timers. I was focused on making a solution that was general
across both types of timers. If you are using a 16-bit timer, you
can use a prescaler of /1 and an OCR value of 20000 and forget about
all of the following reload calcs. Yes, I did choose a 16-bit
timer for this example; I should have used an 8-bit instead; it would
have been less confusing. Sorry about that.)
For example, using a prescaler of /256 gives:
ClocksPerSecond / MillisecondsPerSecond / Prescaler =
(20000000 / 1000) / 256 = 78.125
Put another way, if you use a 20 MHz crystal, a /256 prescaler, and a
reload value of 78.125, you will get one interrupt every millisecond.
Obviously, you don't get to choose a reload value of 78.125; the
closest you can get is 78. The problem is that after 1000
interrupts, you will not have timed one second, you will have timed a
shorter interval. To be precise, you will have timed:
1000 * (78 * 256) cycles or 19968000 cycles
This means that your one-second interval will be 0.9984 seconds, and
your minute will be 59.904 seconds and your hour will be 3594.24
seconds, or nearly six seconds off.
The simplest way to fix this issue is to modify the OCR1A reload value
inside the ISR, adjusting the value occasionally so that after 1000
interrupts, you have used precisely 20000000 cycles.
Given the above conditions, you would need to use a reload of 78 for
seven interrupt intervals, but switch to a reload of 79 for the eighth
interrupt interval. This would give you:
1000 * ((78 * 7) + 79) * 32 cycles or 20000000 cycles
It's easy to implement the above design, but it won't work, in the
sense that it will give you exactly 20000000 cycles per 1000 interrupt
intervals, but you still won't have an accurate second. The
problem here is that crystals drift and have their own frequency
tolerance. A typical Fox 20 MHz crystal from Digikey shows a
frequency stability of +/- 50ppm and a frequency tolerance of +/-
30ppm. That's pretty darned good for a 42-cent part, but your
seccond could still be off by up to 1600 cycles, which adds up over an
Rather than hard-code the use of seven reloads of 78 and one reload of
79, I opted to use named literals for how often I modified the reload
value; I call this trimming in my code and the literals define a trim
value used to modify the reload value in the ISR.
The final step is to test against a reference clock, then adjust the
named literals MSEC_ISR_TRIM_VALUE and (if necessary) RELOAD_1MSEC, and
recompile. Note that your trim value (MSEC_ISR_TRIM_VALUE) should
be a whole divisor of 1000. If it isn't, you will miss the final
trim at the 1000th interrupt. Note also that lower trim values
cause longer intervals, as the greater reload value is used more often;
a trim value of 5 means the greater reload value is used 200 times, but
a trim value of 20 only uses the greater value 50 times.
In my case, I did not have a NIST-traceable interval timer, so I ended
up using a Radio Shack interval timer. With repeated testing and
tweaking, I now have an interval timer that matches the Radio Shack
timer. (Yes, I know, that's not absolutely accurate, but it's
relatively accurate, and that's what I was shooting for.) If you
duplicate this work and have a NIST-traceable timer, I would be
interested to know how closely your final trim values match the nominal
values of 78 for RELOAD_1MSEC and 8 for MSEC_ISR_TRIM_VALUE.
Here is the final code that I'm using in my project:
#define MSEC_ISR_TRIM_VALUE 5
* ISR for Timer1 OCR1A compare
* Control reaches here each time Timer1 reaches its OCR1A
* value. This interrupt is used to define one
* However, there is an issue. The MCU is driven with
a 20 MHz
* crystal but the MCU uses a binary divider chain to
* the interrupt rate. This means that there is no
* divider; you can't divide 20 MHz by a binary prescaler
* an even multiple of cycles for one msec.
* For example, using a prescaler of 256 gives:
* 20000000 / 1000 / 256 = 78.125 per msec
* If you load OCR1A with 78 and set the prescaler to 256,
* get an interrupt every (78 * 256) cycles, or 19,968
* means your msec will be off by 32 cycles and your second
* off by (32 * 1000) or 32,000 cycles. This is really
* The key is to add back in the 0.125 per msec that is
* the reload value in the above equation. Since 0.125
= 1/8, we
* need to use 79 as our our OCR1A load value once every
* For one full second, this will give:
* (78 * 256 * 875) + (79 * 256 * 125) = 20000000 cycles
* which is perfect; our one-second clock will be as
* our crystal.
* However, this isn't necessarily accurate, since the
* has tolerances of its own. So the code below uses a
* literal, MSEC_ISR_TRIM_VALUE, to provide a selected trim
* The trim value is the number of msecs that must elapse
* an additional count is added to the OCR1A value (79 vs 78
* the above example).
* For example, on one of my projects, the above trim value
* 8 gave too much delay and the clock would lose time
* reference clock. After repeated tests, I settled on
* value of 5 and a base reload value of 77, which gave a
* accurate clock.
* Note that the trim value should be an even divisor of
* you won't get the last adjustment when hitting msec #999.
* Note that you don't normally reload the OCR1A value
* ISR, as you see below. The only reason I'm doing
this is to
* ensure the OCR1A value adjusts for the missing fractions
* seconds. If you don't need the accuracy and can
live with a
* constant reload value, you don't need to modify OCR1A
static unsigned int
msecs = 0;
OCR1A = RELOAD_1MSEC;
// this is correct most of the
if ((msecs % MSEC_ISR_TRIM_VALUE) ==
MSEC_ISR_TRIM_VALUE-1) // but on each trim msec...
OCR1A = RELOAD_1MSEC +
1; // we adjust for the missing cycles
// count the msec that just passed
if (msecs == 1000)
// if we have done a
msecs = 0;
// rewind the msecs counter
(ElapsedTimeSecs) // if
big timer is active and non-zero...
ElapsedTimeSecs--; // count the second
that just passed