next topic »

[on:]

I'm looking for a timer library for my project, and haven't found one I consider suitable (yet). I'm hoping someone has one that google didn't find - or maybe I misread some docs.

Background

I've written an LED matrix driver that uses 74595 shift registers. I'm using the Timer1 library to schedule interrupts to strobe the common lines, but would really like to generalize things so I can have more than one device attached. I'd like a library designed for handling multiple simple timers in the background. Possibly even if they don't know about each other.

Requirements

In order of importance.
-

• The library needs to stay out of the loop. This lets out about half the libraries I found, which either require a poll of some kind, or replace loop with a multi-tasking framework.
• Support for multiple, independent timers. None of the libraries that stayed out of the loop clearly did this, though some might have, but didn't say what happened if I instantiated multiple instances of the class or otherwise tried setting up a second timer.
  
• Provides a way to pass data to the callback function. Without this, handling different instances of the same callback (i.e. - multiple instances of the above driver) is a PITA.

The multi-tasking frameworks look really cool, and I look forward to experimenting with some of those, but I'm loathe to let the requirements of a library drive the form of the application.

Does anyone have a library that can do these kinds of things? Anyone interested in such a library should I write one?

Thanks,
<mike

[Reply #1 on:]

leo72 (in italy) has something going on, send him a pm about his timer project.

[Reply #2 on:]

Hello mwmeyer,
I wrote 3 libraries that can managed little scheduled tasks.
Two of them use interrupts, the third doesnt'.
They are leOS, leOS2, and looper.
leOS uses a microcontroller's timer to launch the tasks at the interval specified by the user.
Tasks have be small and doesn't have to use other interrupt based functions.
leOS2 uses the watchdog timer so it preserves the timers for the user's needs.
It can also be set up with a timeout value, to reset the MCU if a task gets into a neverending loop causing the MCU to freeze. They are not complete RTOS but they are easier to use and good for simple tasks.
page on leOS/leOS2
thread on this forum

The last one is looper, it is a millis()-based scheduler and it can call simple jobs.
page on looper

Glad to give you more info if needed.

PS: thanks, Bob 

[Reply #3 on:]

Thanks for the pointers, leo.

Looper misses requirement #1, but that's normal for polling systems.

The all miss on requirement #3, but that seems to be SOP for arduino callbacks. Given that I want to have two timers running the same code with different data, possibly at different intervals, there's no way to get your library to do it.

I'm used to C callbacks, where the callback signature is "int (*)(void *)" instead of "void (*)(void)". This allows 1) the callback to signal errors, and 2) data to be passed into the callback. I'll post more on the thread  for leOS/leOS2.

Thanks,
<mike

[Reply #4 on:]

Regarding the requir. #3, you can use global variables to pass values between the main loop and/ore the taks.

[Reply #5 on:]

For those who didn't switch to the leOS thread, the problem with globals is that it requires a distinct handler for each set of data you want a task to use. For my use case - where the library is setting up the tasks "behind the users back" as it were - this means the library has to know how many LED matrices the users is going to be driving. Adding the ability to pass a parameter means the library can be written to allow the user to create as many instances of the driver class as they need in a straightforward way. To get that flexibility without passing parameters means the task handler for the library needs to be a task scheduler in it's own right.