In general, once an embedded processor's interrupt fires, the interrupt routine clears the interrupt. Usually inside the interrupt routine. Failure to clear the interrupt normally inhibits further interrupts.
That said, in the Arduino paradigm, this is "taken care of" by the Arduino Timer library described here. In the example code:
/*
* Timer1 library example
* June 2008 | jesse dot tane at gmail dot com
*/
#include "TimerOne.h"
void setup()
{
pinMode(10, OUTPUT);
Timer1.initialize(500000); // initialize timer1, and set a 1/2 second period
Timer1.pwm(9, 512); // setup pwm on pin 9, 50% duty cycle
Timer1.attachInterrupt(callback); // attaches callback() as a timer overflow interrupt
}
void callback()
{
digitalWrite(10, digitalRead(10) ^ 1);
}
void loop()
{
// your program here...
}
...you can see that the example does not actually contain "the" Timer interrupt routine but rather a callback() routine which the Timer library calls when the Timer interrupt occurs. Code to clear the Timer interrupt is missing and assumed to be in the Timer library.
Consider this if you are writing you own interrupt routine instead of using the Arduino's Timer library.
I'm going to have to call foul on myself. Clearing interrupts in their own interrupt routine is very common. But looking at this page, where the Atmel timer hardware is directly controlled (that is, the normal Arduino Timer library is not being used) and the real interrupt handler exists in the sketch, I see where this is not done. So, for the Atmel, there must be at least one timer mode where the timer interrupt does not have to be clear for the interrupt to happen again.
If you are using the Arduino's Timer library consider this warning from the Timer's library web page linked to above:
Be careful about trying to execute too complicated of an interrupt at
too high of a frequency, or the CPU may never enter the main loop and
your program will 'lock up'.
Finally, hardware timed interrupts are normally reserved for operations which are time sensitive and occur much faster than executing code can handle. For events that happen on the order of seconds, most applications setup 1 timed interrupt to count off a convenient interval. Say 1 second. Code is used to keep count and call the proper functions at the intended time.