Periodic tasks with long period handled by a timer

Hi guys,

As always I hope the question hasn't been answered n-times...

What's the better way to execute a periodic task with a long period (say minutes or more)??

I could use a millis() but the execution period could be significantly influenced by the execution of other long tasks so I would prefer to use interrupts (as the TimerOne library does but the period is limited to ~8.3 s!).
So, I can generates interrupts every ~8.3 s and counts the necessary interrupts before execute the periodic task (so, for example, if i want to execute a task every 5 minutes, i have to count 36-37 interrupts).
Is there a better way?
Is there an existing library that uses a timer to do this (I looked for this but seems all timing libraries that allows long periods use millis())?
Thank you in advance for your attention and collaborations.

Best regards,
Marco

If you look at the demo Several Things at a Time you will see how millis() is used for non-blocking timing. The trick is to break down a long running task into many small pieces.

Be aware that millis() does not keep time as accurately as a clock and if you need the extra precision to stay in step with a clock over several hours you should use a Real Time Clock module.

…R

You've got it backwards. If it is minutes then interrupts aren't appropriate. Interrupts are for things that happen super fast.

Delta_G:
You've got it backwards.

Who do you mean by "you" ?

...R

Hi guys,

thanks for the answers.

Robin2:
If you look at the demo Several Things at a Time you will see how millis() is used for non-blocking timing. The trick is to break down a long running task into many small pieces.

Maybe my request wasn't so clear.
What i wanted to say is that long tasks (as, for example, long data exchange over internet) could significantly influence the timing of the sketch and cause delay in the execution of the periodic task (and this is the reason why i would prefer interrupts).

Delta_G:
You've got it backwards. If it is minutes then interrupts aren't appropriate. Interrupts are for things that happen super fast.

You're right but, if I want to execute the task at a precise rate (so blocking everything else is running) without an RTC module, using interrupts is the only way?

Thank you in advance for your attention and collaboration.

Best regards,
Marco

Long data exchanges can be cut down to smaller pieces. Timing with millis() or a timer library can du what you want but you may need to re-think some of your code :slight_smile:

Robin2:
Who do you mean by "you" ?

...R

I mean the OP in this statement:

I could use a millis() but the execution period could be significantly influenced by the execution of other long tasks so I would prefer to use interrupts

If you've got minutes to time then you should be able to handle that without involving an interrupt.

See what the OP doesn't understand is that millis() is already driven by an interrupt. He wants to take this 8.3 second interrupt and drive a clock with it. But that's EXACTLY what millis does except it uses a 1/1024 second clock. All the OP is doing with this idea is reinventing something that is already there and already works exactly like what he wants to invent, except that what he wants to create will have lower resolution.

ErVito:
What i wanted to say is that long tasks (as, for example, long data exchange over internet)

A long data exchange over the internet happens one byte at a time.

The technique in the second example in Serial Input Basics will almost certainly be appropriate with very minor adaptation.

…R