there appears to be a bug in the TimerOne library. it appears that when you setup a timer interrupt, the interrupt gets triggered as soon as you start the timer. so, for proper operation, I find myself having to "ignore" the first interrupt. after that, it works correctly.
I'll attache a sketch which demonstrates the problem.
here it is:
http://jason.pepas.com/code/TimerTest/0.1/TimerTest.pde
// TimerTest
// by Jason Pepas (jasonpepas@gmail.com)
// test of the timer-based interrupt routine.
// copyright 2010 jason pepas
// released under the gpl version 2.
#include <TimerOne.h>
// the built-in LED on digital pin 13
int ledPin = 13;
// the initialize() function takes a "long", but that's ambiguous. it turns out it
// takes a signed 32-bit int, so let's just call it that (int32_t).
// this is in microseconds (ie, this is 3 seconds).
int32_t timeout = 3000000;
void setup()
{
// initialize the digital pin as an output
pinMode(ledPin, OUTPUT);
// setup the timeout timer
Timer1.initialize(timeout);
Timer1.attachInterrupt(timeoutOccurred);
Timer1.start();
}
void loop()
{
// loop forever, handling interrupts
;
}
byte ledState = LOW;
void timeoutOccurred()
{
// each time the timeout happens, toggle the LED.
// this will allow you to visually verify the timeout period.
// note that there appears to be a bug in the TimerOne library which causes the timer interrupt
// to be called immediately. thus the LED will appear to start in the HIGH state.
if (ledState == HIGH) ledState = LOW;
else if (ledState == LOW) ledState = HIGH;
digitalWrite(ledPin, ledState);
}
in the above sketch, the LED on pin 13 toggles each time the interrupt is triggered. it should start in the LOW position, but if you try it, you'll see it starts in the HIGH position. something is causing the interrupt to get triggered right away, rather than after the first timeout.
I'm trying this and I don't get the results you do. The pin 13 LED starts off unlit, and lights after three seconds. I think that's what it should do if the ledState variable starts out LOW.
Am I missing something here?
it should start in the LOW position, but if you try it, you'll see it starts in the HIGH position.
By "it" do you mean the ledState variable or the LED?
The LED is off for the first three seconds of the sketch because there has been no
digitalWrite(ledPin, HIGH);
executed yet. The first time a digitalWrite() is executed is when the interrupt routine is called for the first time, three seconds into the running of the sketch.
I added some println() statements for debugging purposes. The debugging lines I added are highlighted in the sketch below. They basically snapshot the variable "ledState" before the timer is initialized, again right after the timer is started, and every second in the loop(). I added "volatile" to the definition of the variable because I use it in more than one function, but my results were the same with and without "volatile".
// TimerTest
// by Jason Pepas (jasonpepas@gmail.com)
// test of the timer-based interrupt routine.
// copyright 2010 jason pepas
// released under the gpl version 2.
#include <TimerOne.h>
// the built-in LED on digital pin 13
int ledPin = 13;
// the initialize() function takes a "long", but that's ambiguous. it turns out it
// takes a signed 32-bit int, so let's just call it that (int32_t).
// this is in microseconds (ie, this is 3 seconds).
int32_t timeout = 3000000;
void setup()
{
// initialize the digital pin as an output
pinMode(ledPin, OUTPUT);
[glow] Serial.begin(115200);
Serial.println("Start...");
reportState();[/glow]
// setup the timeout timer
Timer1.initialize(timeout);
Timer1.attachInterrupt(timeoutOccurred);
Timer1.start();
[glow] reportState();
Serial.println("End of setup(), next prints are from loop()");[/glow]
}
void loop()
{
// loop forever, handling interrupts
[glow] reportState();
delay(1000);[/glow]
;
}
[glow]volatile[/glow] byte ledState = LOW;
void timeoutOccurred()
{
// each time the timeout happens, toggle the LED.
// this will allow you to visually verify the timeout period.
// note that there appears to be a bug in the TimerOne library which causes the timer interrupt
// to be called immediately. thus the LED will appear to start in the HIGH state.
if (ledState == HIGH) ledState = LOW;
else if (ledState == LOW) ledState = HIGH;
digitalWrite(ledPin, ledState);
}
[glow]void reportState( void )
{
// Report the ledState
Serial.print("state: ");
Serial.print(ledState, DEC);
Serial.print(" millis: ");
Serial.println(millis(), DEC);
}[/glow]
Output from the debugging run follows. This output shows me that the first time the "ledState" variable is toggled is after 3 seconds of run time, not right after you start the timer.
Start...
state: 0 millis: 2
state: 0 millis: 4
End of setup(), next prints are from loop()
state: 0 millis: 10
state: 0 millis: 1012
state: 0 millis: 2015
state: 1 millis: 3018
state: 1 millis: 4021
state: 1 millis: 5024
state: 0 millis: 6027
state: 0 millis: 7030
state: 0 millis: 8033
state: 1 millis: 9036
state: 1 millis: 10039
state: 1 millis: 11042
state: 0 millis: 12045
state: 0 millis: 13048
. . .
I would guess that you encountered the problem in some other code, and you reduced the problem to the minimum in the test sketch you posted. Is that true? If so, does my analysis make sense in the context of your original code?