[Solved] ESP 32 Timer Interrupts – ‘Unlimited’ Programmatic User Definable Timers

Recap - FreeRTOS software timer interrupts are defined to interrupt by multiples of a 'tick'.  So how long is a tick?

I have just 'measured' the timing for a 'tick' on an Arduino UNO (it will be the same for the Mega as they have the same clock speeds), and it turns out that it is approximately 16.13 milliseconds.  So, on this architecture, if using a FreeRTOS software timer interrupt I would expect that it can be clocked faster that this, ie much faster than 16.13 milliseconds.  

As I said, I expect the ESP to deliver much better performance as it clock 5 x faster.

This does not, of course, have any bearing on implementing a hardware timer interrupt which provides much better time resolutions.

Ron B

@zander

If you have defined a hardware timer interrupt by firstly reducing by a factor of 80 then a further factor of 40,000 then you timer interrupt will be triggering every 1/25 second ( ie 25 htz). I presume your code looks something like this:

...
  timer = timerBegin(timer_num, 80, true);  // 80 Mhz processor, scale down to 1 Mhz
  timerAttachInterrupt(timer, &timer_ISR, true);  // link to our interrupt service routine (ISR)
  timerAlarmWrite(timer, 40000, true);    // freq = 1000000/40000 = 25 htz
  timerAlarmEnable(timer);         // start timer
...

The FreeRTOS software timer interrupts are dealt with quite differently and, as yet, I still do not know how fast they can be driven! 

Regards

Ron B

@ronbentley1 My code is as follows

  TimerKitchen = timerBegin(0, 40000, true);    // timer is now 1/2000 or every 2ms tick
  if (NULL == TimerKitchen) LOG(" TimerKitchen is NULL ");
  timerAttachInterrupt(TimerKitchen, &TimerKitchen_ISR, Edge);
  timerAlarmWrite(TimerKitchen, DurationK, AutoReload);
  timerAlarmDisable(TimerKitchen);

 where DurationK is 30 mins, so 30*60*2000 or 3,600,000

but I have pretty much abandoned it as the wrong ISR gets fired for some reason I can't fathom. Yes I know the timers are 0 based, 0,1,2,3 and in some places known as 1,2,3,4 but that isn't it.

I will leave it for awhile and think about other things.

@zander 

Cant fault the logic in what you have posted.

Is your value

DurationK

A 64 bit value. The parameter in the function timeralarlmwrite is uint64_t for duration. Ie ULL.

Ron B

@ronbentley1 I think so, it's uint64_t DurationK = 0;

@zander 

DurationK = 0;?

Are you sure? Is this not setting the alarm frequency at 0?

Ron B

@ronbentley1 Sorry, I was showing you the type, not the value, the value is 30 mins so

30 * 60 * 2000 is the actual value of 3,600,000.

@ronbentley1 To review. A timer is set (only one is set as confirmed by log) and at the correct time (as confirmed by log) an ISR is triggered. The problem is it's the wrong ISR. I don't recall now if it's always wrong or random. Now that I have mqtt logging on my RaspberryPi I can do more logging and make it selective. I am also going to look into using mqtt to send messages from the pi to the esp32 to change it's behaviour in real time. I have RV work to do while the weather is good but mostly just need to distance myself from this project to eliminate any unintentional bias. My gut feeling based on over 50 yrs of troubleshooting computer systems is this is a memory walker problem. I have tried to move things around in memory and inserted variables to force alignment but so far no luck. I am really worried that the doc's say the timers are 0 based, ie 0, 1, 2, 3 but what if some piece of code is assuming 1 based, since the misfiring timer is one off, that does raise the possibility of a confusion between 0 and 1 based.

In any case, I will not be doing any more with this project until the winter sets in and outside work is over. Then I will fill the sketch with logging etc to finally get it working.

@zander 

👍