A bug and some ideas for further development

[Anonymous]

Hi Allen,

I think I found a bug in the code:

#define NUM_TASKS(T) (sizeof(T) / sizeof(Task))

ought to be:

#define NUM_TASKS(T) (sizeof(T) / sizeof(Task*))

Best Regards,

Marcello

[Alan Burlison]

Thanks for the bug report, I've updated the macro.

You can always subclass and/or replace the Task and TaskScheduler classes if they don't fit your needs but there's always a tradeoff - adding more functionality has a cost, and the aim is to be as lightweight as possible. The 'active' additions you suggest have both a performance and a space cost so I don't believe they belong in the base classes. Adding an 'active' flag is easy enough to do in a subclass in the same way that TimedTask is done.

I don't use the Arduino any longer environment and most of the things I've put here on SF are replacements for the very few pieces of functionality that it provided and that I still need. I've therefore no interest in tight integration with the Arduino environment, nor in reimplementing parts of the Arduino API. My dissatisfaction with much of the Arduino environment is the reason why I wrote my own versions in the first place.

As for timer wraparound, detecting when the tick counter has wrapped isn't the problem, it's knowing what to do when it happens. Assume a counter that wraps every 10 ticks, if the current tick is 8 and I have a task with a next-run tick of 2, is that in the past or the future? It's very difficult to handle this in a way that is guaranteed to work under all circumstances, other than increasing the size of the timer so it doesn't ever wrap. For example a 2-part counter using 32 bit seconds + 16-bit milliseconds would give well over 100 years before wraparound. However nothing I have would be powered up long enough for the current 50-day wraparound to be a problem anyway,