Problems with Timer Interrupt


I have a problem with the TimerInterrupt with the [TimerOne] library.

I hab a code that reads out sensors via I²C and prints them out. At the begining and the end of the readout-funktion I toggle an IO. With an oszilloskop I then got the average time this needs. (approx 75ms including printout over Serial).

I now want to run this funktion at fixed timeintervals (logicaly). Based on the time I got on the function itself I picked 100ms cykles. when i run the program now it does one cykle and freeces up halfway throught the next.

To get to the root of this problem I began experimenting with the most basic of timerinterrupt codes possible:

#include "TimerOne.h"

void setup()
  pinMode(7, OUTPUT);          //Pin for timing

  Timer1.initialize(5000);        //5ms


void callback()
  delay(1);                                     //need that or the oszi won't pick it up

void loop()
{  // your program here...

with this code (approx time 2ms) it was clear, that the Serial.println is not a very stable predictable function. The time would aperiodicaly jump in duration to up to 3.5ms. With more chars in the print the time would ovliously be longer.

when i run the code and the runingtime of one cykle would only slightly overlap with the next the timer, again, seems to crash.

is this normal? In my mind a TimerInterrupt would automaticly start the next cycle and don't give a s**t if the otherone has finished. or at least jump this timercycle. as long as the code is running the time is spoton, but then it just stops.

is there some secret how to do this properly? a diffrent timerinterrupt?

Hardware: ArduinoOne

I really am just guessing here. I have only had a arduino for two weeks and spent most of the play time getting rid of the IDE.

But, are timer interrupts special? If not, you can't use other things interrupt dependent inside a isr. Like delay(). I have not looked at the Serial code, but I would not be surprised if that also uses interrupts. Actually, I bet it does.

Could be wrong..

You can disable interrupts in the beginning of the interrupt handler and enable them again at the end. That will ignore interrupts made in between.

Cheers, Jarkko

OK. based on thensomes sugestion i looked at the delays more closely. Those use the internal timer0 and the interrupt uses timer1 so there should be no problem i think.

I also tried the disable/enable of the interrupt at the beginning and the end of the code but that don't seem to work. I still get the stops.

I now threw out the serial print and the cycletimes are a lot more consistant. there are still fluctuations and as told before: if the cycles meet everything just stops

Yeah, I never do anything 'fancy' in a isr. If I need some debug stuff I set a flag and then outside of isr I print or whatever.

Most of the issues I've had when decoding a 433mhz radio signal has been my debug serial prints being wacky. I now collect all I want to print and print them all at once. Treating serial.print as printf is going to give you a bad time, as it did me.

In general, you can’t do serial io in an ISR. Serial io is also interrupt driven.

Ok. I just had an idea for a woraround or possibly the proper way to do it. (i'm no a software engineer :-P) it doesn't answer my initial question concerning the behavior of the timer interrupt.

with the interrupt i now just increase a flag.

in the loop the function is triggered if this flag is set. additionaly the flag is emediately reset. I am aware, that this is the not realtime, but i can detect when and how often this happend. I can live with that.

So thank you for your help guys