Computing stuff tied to the physical world

Scheduling multiple tasks

In Software on Oct 17, 2010 at 00:01

Since Room Nodes are going to become more sophisticated in terms of timing, I’m adding some support code to simplify my work later on. In most cases, I think it’s not a good idea to start generalizing too early, but this is a pretty common utility: scheduling multiple activities in parallel. No rocket science, and badly needed…

So here’s a little “Scheduler” class I’m going to add to the Ports library:

Screen Shot 2010 10 17 at 00.00.53

Nothing fancy. My main concern is to keep RAM usage low. So the idea is that you can have a fixed number of tasks, each one with (at most) one timer running. Timers can be started and cancelled at will. The term “task” is used very loosely here: anything that needs to have an independent timer mechanism can be treated as a separate task. This is not multi-tasking or threading – just a way to manage activities which need to be performed some time into the future.

Unlike the Millitimer class, which works for durations up to 60000 milliseconds, the Scheduler class works in tenths of seconds, and supports durations from 0 to 6000 seconds, i.e. over an hour and a half. A zero duration means: run the associated task as soon as possible.

Probably best to show this in action with an example:

Screen Shot 2010 10 16 at 23.56.53

The way to use the scheduler, is to define an enum with all the tasks there can be, plus a “TASK_LIMIT” value, which is in fact simply the number of tasks.

Then you declare a “Scheduler” instance, and give it that TASK_LIMIT value, so it can allocate the proper amount of memory (each task needs only 2 bytes).

The only remaining thing to do is call the “poll()” member and handle each task request in a big switch statement.

The demo will blink two LEDs at different rates, the classical (and simplest) example of doing two different things at the same time. Eh… almost the same time.

I’m still putting the finishing touches on this code and making sure that this will play nicely with low-power and power-down modes, so it hasn’t been checked in yet – it should all be ready in at most a day or two. At which time this will become part of the Ports library, along with the above “schedule.pde” example sketch.

  1. Nice code ! it will be very useful for EVERY JeeNode developers…

    Regards, Gennaro

  2. Did you have a look at this project: ?

  3. Ooooh, how did you know what I wanted? (Although I need a slightly faster interval – easy!) :-)

    Does the class put the JeeNode into a sleep mode of any sort between intervals?

  4. It might be wise to consider sorting functionality into libraries with meaningful names. A scheduler is very handy (thanks !) but it has not so much to do with the ports of the Jeenode.

    But everybody is a critic these days. Keep going !

  5. (Drat, I hate it when my browser loses everything I’ve typed in because the page got refreshed at some point…)

    Yes, this has been mentioned on the weblog before. It’s a very interesting project – both in concepts and in implementation – but I find it hard to make such a big transition and replace C/C++ by Occam, which I’ve never really used yet. To put it differently: the pain of C/C++ hasn’t reached the level where I’m willing to invest in such a major switch.

    a sleep mode of any sort between intervals

    I’m woikin’ on it….

    Which gives me an opportunity to also reply to Ronald’s (valid) point: I’m always in a terrible fight with modularity, when I find out that everything tends to link to everything else over time. In this case, the Scheduler class will optionally deal with some low-power capabilities, as supplied by the Sleepy class. Putting everything into separate libraries leads to (brittle) dependencies. See the Ports.h vs RF12.h mess, which keeps bugging me to no end.

    Trouble is that if lib A uses lib B internally, then your sketch has to include A and B headers, even though you don’t care or should even need to know this dependency. So what the Arduino IDE forces you to do is include all the headers used somewhere, directly or indirectly. It’s pushing me in the opposite direction in fact: putting everything I write into the Ports library (at which point the name is not a very good one anymore). In the hope that the linker will do the right thing and strip unused stuff.

Comments are closed.