Task Scheduler

cooperative multitasking for Arduino microcontrollers

Version 1.8.4: 2015-11-17

OVERVIEW:

A lightweight implementation of cooperative multitasking (task scheduling) supporting:

Periodic task execution (with dynamic execution period in milliseconds – frequency of execution)
Number of iterations (limited or infinite number of iterations)
Execution of tasks in predefined sequence
Dynamic change of task execution parameters (frequency, number of iterations, callback methods)
Power saving via entering IDLE sleep mode when tasks are not scheduled to run
Support for event-driven task invocation via Status Request object
Support for task IDs and Control Points for error handling and watchdog timer
Support for Local Task Storage pointer (allowing use of same callback code for multiple tasks)

TASK:

“Task” is a container concept that links together:

Program code performing specific task activities (callback methods)
Execution interval
Number of execution iterations
(Optionally) Execution event (Status Request)
(Optionally) Pointer to a Local Task Storage area

Tasks perform certain functions, which could require periodic or one-time execution, update of specific variables, or waiting for specific events. Tasks also could be controlling specific hardware, or triggered by hardware interrupts.

For execution purposes Tasks are linked into execution chains, which are processed by the Scheduler in the order they were added (linked together).

Each task performs its function via a callback method. Scheduler calls Task’s callback method periodically until task is disabled or runs out of iterations. In addition to “regular” callback method, two additional methods could be utilized for each task: a callback method invoked every time the task is enabled, and a callback method invoked once when the task is disabled. Those two special methods allow tasks to properly initiate themselves for execution, and clean-up after execution is over (E.g., setup pin modes on enable, and always bring pin level to LOW at the end).

Tasks are responsible for supporting cooperative multitasking by being “good neighbors”, i.e., running their callback methods quickly in a non-blocking way, and releasing control back to scheduler as soon as possible.

Scheduler is executing Tasks' callback methods in the order the tasks were added to the chain, from first to last. Scheduler stops and exists after processing the chain once in order to allow other statements in the main code of loop() method to run. This is referred to as a “scheduling pass”.

(Normally, there is no need to have any other statements in the loop() method other than the Scheduler's execute() method).

Below is the flowchart of a Task lifecycle:

TaskScheduler library maybe compiled with different compilation controls enabled/disabled. This is a way to limit TaskScheduler functionality (and size) for specific purpose (sketch). This is achieved by defining specific #define paramenters before TaskScheduler.h header file. Specifically:

If compiled with _TASK_SLEEP_ON_IDLE_RUN enabled, the scheduler will place processor into IDLE sleep mode (for approximately 1 ms, as the timer interrupt will wake it up), after what is determined to be an “idle” pass. An Idle Pass is a pass through the task chain when no Tasks were scheduled to run their callback methods. This is done to avoid repetitive idle passes through the chain when no tasks need to be executed. If any of the tasks in the chain always requires immediate execution (aInterval = 0), then there will be no IDLE sleep between task's callback method execution.

Note: Task Scheduler uses millis() to determine if tasks are ready to be invoked. Therefore, if you put your device to any “deep” sleep mode disabling timer interrupts, the millis() count will be suspended, leading to effective suspension of scheduling. Upon wake up, active tasks need to be re-enabled, which will effectively reset their internal time scheduling variables to the new value of millis(). Time spent in deep sleep mode should be considered “frozen”, i.e., if a task was scheduled to run in 1 second from now, and device was put to sleep for 5 minutes, upon wake up, the task will still be scheduled 1 second from the time of wake up. Executing enable() method on this tasks will make it run as soon as possible. This is a concern only for tasks which are required to run in a truly periodical manner (in absolute time terms).

In addition to time-only (millis() only) invocation, tasks can be scheduled to wait on an event employing StatusRequest objects (more about Status Requests later).

Consider a scenario when one task (t1) is performing a function which affects execution of many tasks (t2, t3). In this case the task t1 will “signal” completion of its function via Status Request object. Tasks t2 and t3 are “waiting” on the same Status Request object. As soon as status request completes, t2 and t3 are activated.

Alternative scenario is the ne task (t1) and waiting for the completion of a number of tasks (t2, t3). When done, t2 and t3 signal completion of their functions, t1 is invoked.

Please see the code examples at the end of this document, and included with the library package for details.

COMPILE PARAMETERS:

This library could be compiled in several configurations.

Parameters (#defines) defining what functionality should or should not be included need be defined before the library header file in the body of arduino sketch.

#define _TASK_TIMECRITICAL

...will compile the library with time critical tracking option enabled.

Time critical option keeps track where next execution time of the task falls, and makes it available via API through Task::getOverrun() method. If getOverrun returns a negative value, this Task’s next execution time point is already in the past, and task is behind schedule. This most probably means that either task’s callback method's runtime is too long, or the execution interval is too short (and therefore schedule is too aggressive).

A positive value indicates that task is on schedule, and callback methods have enough time to finish before the next scheduled pass.

#define _TASK_SLEEP_ON_IDLE_RUN

...will compile the library with the sleep option enabled (AVR boards only).

When enabled, scheduler will put the microcontroller into SLEEP_MODE_IDLE state if none of the tasks’ callback methods were activated during execution pass. IDLE state is interrupted by timers once every 1 ms. Putting microcontroller to IDLE state helps conserve power. Device in SLEEP_MODE_IDLE wakes up to all hardware and timer interrupts, so scheduling is kept current.

#define _TASK_STATUS_REQUEST

…will compile TaskScheduler with support for StatusRequest object. Status Requests are objects allowing tasks to wait on an event, and signal event completion to each other.

#define _TASK_WDT_IDS

…will compile TaskScheduler with support for Task IDs and Control Points. Each task can be (and is by default) assigned an ID, which could be used to identify the task in case there is a problem with it. Furthermore within the task, Control Points could be defined to further help with pinpointing potential problem areas. For instance, the tasks which deal with external resources (sensors, serial communications, anything hardware dependent) can be blocked (or hung), by failed hardware. In this case, a watchdog timer could be employed to trap such a failed task, and identify which one (by task id) and where in the task (by a control point) the problem is likely located.

Note: by default, talk IDs are assigned sequentially (1, 2, 3, …) to the tasks as they are being created. Programmer can assign a specific task id. Task ids are unsigned integers.

Control points provide a way to identify potential problem points within a task. Control points are unsigned integers as well. Please note that there is only one control point per task, and it is set to zero when the task’s callback method is invoked (this is done to prevent “stray” control point from previous task(s) confusing the matters.

Example #7 contains a test of task ID and control points functionality.

#define _TASK_LTS_POINTER

…will compile TaskScheduler with support for Local Task Storage pointer (LTS). LTS is a generic (void*) pointer which could be set to reference a variable or a structure specific to a particular task. A callback method can get access to specific variables by getting reference to a currently running task from the scheduler, and then casting (void*) LTS pointer to the appropriate pointer type.

#define _TASK_ROLLOVER_FIX

…will compile TaskScheduler with support for millis() rollover approximately every 47 days. Only required if you plan for your sketch to run for extended amount of time (over 47 days).

The problem here is when scheduler calculates next execution time for a task, a rollover may place next execution time “in the past” and cause task to be invoked incorrectly once every 47 days.

NOTE: above parameters are DISABLED by default, and need to be explicitly enabled by placing appropriate #define statements in front of the #include statement for the TaskScheduler header file.

TASK PRIORITY AND COOPERATIVE MULTITASKING:

TaskScheduler does not support task priority functionality. I have been thinking a lot about it (especially since Symbian's Active Objects, which TaskScheduler is inspired by, support it), but decided against it.

This is why:

1. Execution chains are simple and efficient. The main idea is to minimize scheduling overhead by Scheduler going through the chain. Implementing true priority would require looking ahead through the entire chain, ranking and aging tasks by priorities. It would slow the execute() loop significantly.

2. TaskScheduler is NOT a pre-emptive multi-tasking library. Nor is it a Real-Time OS. There is no way to break execution of one task in favor of another. Therefore callback methods require careful programming for cooperative behavior.

This has, however, significant benefits: you don't need to worry about concurrency inside the callback method, since only one callback method runs at a time, and could not be interrupted. All resources are yours for that period of time, noone can switch the value of variables (except interrupt functions of course...), etc. It is a stable and predictable environment, and it helps a lot with writing stable code.

A number of things could be done instead of priorities:

1. Schedule your critical tasks to run more frequently than the other tasks

.
(Since you can control the interval, you could also change the task to run more or less frequently as the situation demands).

2. If one particular callback routine is critical, create a couple of tasks referring to the same callback and "sprinkle" them around the chain:

Scheduler ts;

Task t1(20, TASK_FOREVER, &callback1, &ts);

Task t2(1000, TASK_FOREVER, &callback2, &ts);

Task t3(20, TASK_FOREVER, &callback1, &ts);

Task t4(1000, TASK_FOREVER, &callback4, &ts);

t3.delay(10);

Note that t1 and t3 call the same callback method, and are shifted in time by 10 millis. So effectively callback1 will be called every 10 millis, but would be "sandwiched" between t2 and t4.

3. Use short efficient callback methods written for cooperative multitasking.

What that means is:

a) DO NOT use Arduino's delay() function. It is blocking and will hold the entire chain. Instead break the callback method into two, switch the callback method of the task where delay is necessary and delay the task by that number of millis. You get your delay, and other tasks get a chance to run:

instead of:

void callback() {

... stuff

delay(1000);

... more stuff

}

do this:

void callback1() {

... stuff

t1.setCallback(&callback2);

t1.delay(1000);

}

void callback2() {

... more stuff

t1.setCallback(&callback1);

}

b) Same goes to pulseIn() function. If you have to use it, set the timeout parameter such that it is not a default 1 second. PulseIn functionality could be achieved via pin interrupts, and that solution is non-blocking.

c) Do don run long loops (for or do/while) in you callback methods. Make the main arduino loop be the loop driver for you:

instead of:

void callback() {

for(int i=0; i<1000; i++) {

... stuff // one loop action

}

do this:

Task t1(TASK_IMMEDIATE, 1000, &callback);

void callback() {

int i = t1.getRunCounter() -1;

... stuff // one loop action

}

or this:

Task t1(TASK_IMMEDIATE, 1000, &callback, true, &t1On);

int i;

bool t1On() {

i = 0;

return true;

}

void callback() {

... stuff // one loop action

i++;

}

REMEMBER: you are already inside the loop - take advantage of it.

d) Break long running callback methods into several shorter ones, and pass control from one to the other via setCallback() method:

Task t1(TASK_IMMEDIATE, TASK_FAREVER, &callback);

void callback() {

... do some stuff

t1.setCallback(&callback_step2);

}

void callback_step2() {

... do more stuff

t1.setCallback(&callback_step3);

}

void callback_step3() {

... do last part of the stuff

t1.setCallback(&callback);

t1.delay(1000);

}

This will execute all parts of the callback function in three successive steps, sheduled immediately, but allowing other tasks in the cahin to run. Notince that task is scheduled to run immediately, and 1 second period is achieved by delaying the task for 1000 millis at the last step.

Alternatively you could schedule the task to run every 1000 millis and use forceNextIteration() method in steps 1 and 2 (but not 3!)

Task t1(1000, TASK_FOREVER, &callback);

void callback() {

... do some stuff

t1.setCallback(&callback_step2);

t1.forceNextIteration();

}

void callback_step2() {

... do more stuff

t1.setCallback(&callback_step3);

t1.forceNextIteration();

}

void callback_step3() {

... do last part of the stuff

t1.setCallback(&callback);

}

e) Compile the library with _TASK_TIMECRITICAL enabled and check if your tasks are falling behind schedule. If they are - you need to optimize your code further (or maybe re-evaluate your schedule). If they are not - all is well and you don't need to do anything. E.g., I have a spider robot which needs to measure distance, control motors, and keep track of the angle via querying gyroscope and accelerometer every 10 ms. The idea was to flash onboard LED if any of the tasks fall behind. At 10 ms interval for the gyro the LED does not flash, which means none of the tasks are blocking the others from starting on time.

API DOCUMENTATION:

TASKS:

CREATION:

Task();

Default constructor.

Takes no parameters and creates a task that could be scheduled to run at every scheduling pass indefinitely, but does not have a callback method defined, so no code execution will actually take place.

All tasks are created disabled by default.

Task(unsigned long aInterval, long aIterations, void (*aCallback)(), Scheduler* aScheduler, bool aEnable, bool (*aOnEnable)(), void (*aOnDisable)())

Constructor with parameters.

Creates a task that is scheduled to run every <aInterval> milliseconds, <aIterations> times, executing <aCallback> method on every pass.

aInterval is in milliseconds (default = 0)
aIteration in number of times, -1 for indefinite execution (default = -1)
Note: Tasks do not remember the number of iteration set initially. After the iterations are done, internal iteration counter is 0. If you need to perform another set of iterations, you need to set the number of iterations again.
Note: Tasks which performed all their iterations remain active.
aCallback is a pointer to a void callback method without parameters (default = NULL)
aScheduler – optional reference to existing scheduler. If supplied (not NULL) this task will be appended to the task chain of the current scheduler). (default = NULL)
aEnable – optional. Value of true will create task enabled. (default = false)
aOnEnable is a pointer to a bool callback method without parameters, invoked when task is enabled. If OnEnable method returns true, task is enabled. If OnEnable method return false, task remains disabled (default = NULL)
aOnDisable is a pointer to a void callback method without parameters, invoked when task is disabled (default = NULL)

All tasks are created disabled by default (unless aEnable = true). You have to explicitly enable the task for execution.

NOTE: OnEnable callback method is called immediately when task is enabled, which could be well ahead of the scheduled execution time of the task. Please bear that in mind – other tasks, hardware, serial interface may not even be initialized yet. It is always advisable to explicitly enable tasks with OnEnable methods after all initialization methods completed (e.g., at the end of setup() method)

Enabled task is scheduled for execution as soon as the Scheduler's execute() methods gets control. In order to delay first run of the task, use enableDelayed or delay method (for enabled tasks) method.

Task(void (*aCallback)(), Scheduler* aScheduler, bool (*aOnEnable)(), void (*aOnDisable)())

If compiled with support for Status Request objects, this constructor creates a Task for activation on event (since such tasks must run waitFor() method, their interval, iteration and enabled status will be set by that method (to 0, 1 and false respectively).

INFORMATION

The following 3 “getter” methods return task status (enabled/disabled), execution interval in milliseconds, number of remaining iterations.

bool isEnabled()

unsigned long getInterval()

long getIterations()

long getOverrun()

If library is compiled with _TASK_TIMECRITICAL enabled, tasks are monitored for “long running” scenario. A “long running” task is a task that does not finish processing its callback methods quickly, and thus creates a situation for itself and other tasks where they don't run on a scheduled interval, but rather “catch up” and are behind. When task scheduler sets the next execution target time, it adds Task's execution interval to the previously scheduled execution time:

next execution time = previous execution time + task execution interval

If next execution time happens to be already in the past (next execution time < millis()), then task is considered overrun. GetOverrun method returns number of milliseconds between next execution time and current time. If the value is negative, the task has overrun (cut into the) next execution interval by that many milliseconds.

Positive value indicate number of milliseconds of slack this task has for execution purposes.

unsigned long getRunCounter()

Returns the number of the current run. “Current run” is the number of times a callback method has been invoked since the last time a task was enabled.

NOTE: The runCounter value is incremented before callback method is invoked. If a task is checking the runCounter value within its callback method, then the first run value is 1.

If task T1 is checking the runCounter value of another task (T2) , then value = 0 indicates that T2 has not been invoked yet, and value = 1 indicates that T2 has run once.

bool isFirstIteration()

Indicates whether current pass is (or will be) a first iteration of the task.

bool isLastIteration()

For tasks with a limited number of iterations only, indicates whether current pass is the last iteration.

CONTROL:

void enable();

Enables the task, and schedules it for immediate execution (without delay) at this or next scheduling pass depending on when the task was enabled. Scheduler will execute the next pass without any delay because there is a task which was enabled and requires execution.

NOTE: if task being enabled is not assigned to a scheduler and is not part of execution chain, then task will not be enabled.

NOTE: enable() invokes task’s OnEnable method (if not NULL) immediately, which can prepare task for execution. OnEnable must return a value of true for task to be enabled. If OnEnable returns false, task remains disabled. OnEnable is invoked every time enable is called, regardless if task is already enabled or not. Alignment to current millis() is performed after OnEnable exits, so any changes to the interval inside OnEnable is taken into consideration.

NOTE: in the event enable() method is called inside the OnEnable callback method (thus basically creating indefinte loop), TaskScheduler will only call OnEnable once (thus protecting the Task against OnEnable infinite loop).

bool enableIfNot();

Enables the task only if it was previously disabled. Returns previous enable state: true if task was already enabled, and false if task was disabled. Since enable() schedules Task for execution immediately, this method provides a way to activate tasks and schedule them for immediate execution only if they are not active already.

void delay();

Schedules the task for execution after a delay (aInterval), but does not change the enabled/disabled status of the task.

NOTE: a delay of 0 (zero) will delay task for current execution interval. Use forceNextIteration() method to force execution of the task’s callback during immediate next scheduling pass.

void forceNextIteration();

Schedules the task for execution during immediate next scheduling pass.

Note: Task’s schedule is adjusted to run from this moment in time. For instance: if a task was running every 10 seconds: 10, 20, 30, .., calling forceNextIteration at 44th second of task execution will make subsequent schedule look like: 44, 54, 64, 74, ..

void enableDelayed();

Enables the task, and schedules it for execution after task's current scheduling interval (aInterval).

void enableDelayed (unsigned long aDelay);

Enables the task, and schedules it for execution after a specific delay (aDelay, which maybe different from aInterval).

void restart();

For tasks with limited number of iterations only, restart method will re-enable the task, set the number of iterations back to last set value, and schedule task for execution as soon as possible.

void restartDelayed (unsigned long aDelay);

Same as restart() method, with the only difference being that Task is scheduled to run first iteration after a delay = aDelay milliseconds.

bool disable();

Disables the task. Scheduler will not execute this task any longer, even if it remains in the chain. Task can be later re-enabled for execution.

Return previous enabled state: true if task was enabled prior to calling disable, and false otherwise.

If not NULL, task’s OnDisable method is invoked immediately. OnDisable is invoked only if task was in enabled state. Calling disable 3 times for instance will invoke OnDisable only once.

void set(unsigned long aInterval, long aIterations, void (*aCallback)() , bool (*aOnEnable)() , void (*aOnDisable)());

Allows dynamic control of task execution parameters in one method call.

Note: OnEnable and OnDisable parameters can be omitted. In that case they will be assigned to NULL and respective methods will no longer be called.

Next five “setter” methods allow changes of individual task execution control parameters.

void setInterval (unsigned long aInterval)

void setIterations (long aIterations)

void setCallback (void (*aCallback)())

void setOnEnable (bool (*aCallback)())

void setOnDisable (void (*aCallback)())

Note: Next execution time calculation takes place after the callback method is called, so new interval will be used immediately by the scheduler. For the situations when one task is changing the interval parameter for the other, setInterval method calls delay explicitly to guarantee schedule change, however it does not enable the task if task is disabled.

Note: Tasks that ran through all their allocated iterations are disabled. SetIterations() method DOES NOT enable the task. Either enable explicitly, or use restart methods.

STATUS REQUEST METHODS:

void waitFor(StatusRequest* aStatusRequest, unsigned long aInterval = 0, long aIterations = 1)

void waitForDelayed(StatusRequest* aStatusRequest, unsigned long aInterval = 0, long aIterations = 1)

If compiled with support for Status Requests, these methods make task wait for the completion of aStatusRequest event.

By default waitFor() sets tasks interval to 0 (zero) for immediate execution when event happens, and also sets the number of iterations to 1. However, you can specify different interval and number of iterations.

By default waitForDelayed() sets tasks interval to a supplied value or (if omitted or zero) keeps the current interval, so delayed execution will take place when the event happens. It also sets the number of iterations to 1 by default if not supplied.

When Status Request object completes, all tasks waiting on it are executed during next scheduling pass. Tasks waiting via waitFor() method are executed immediately. Tasks waiting via waitForDelayed() method are activated, but executed after current or supplied interval delay.

Note: aStatusRequest should be “activated” by calling setWaiting() method before making a task wait on it. Otherwise, the task will execute immediately.

The sequence of events to use Status Request object is as follows:

Create a status request object
Activate status request object (calling its setWaiting() method)
Set up tasks to wait of the event completion
Signal completion of event(s)

StatusRequest* getStatusRequest()

Returns a StatusReqeust object this Task was waiting on.

TASK ID, CONTROL POINTS METHODS:

void setId(unsigned int aID);

If compiled with support for Task IDs, this method will set the task ID explicitly.

Calling this method is not necessary as task IDs are assigned automatically during task creation: 1, 2, 3, …

unsigned int getId();

If compiled with support for Task IDs, this method return current task’s ID.

void setControlPoint (unsigned int aPoint);

If compiled with support for Task IDs, this method will set a control point in the task’s code. Control points are similar to “try…catch” blocks, with control point ID specifying where in the code the “try” part started, and a mechanism like watchdog timer providing the “catch” functionality.

unsigned int getControlPoint()

If compiled with support for Task IDs, this method will return currently set control point for this task.

LOCAL TASK STORAGE METHODS:

void setLtsPointer(void *aPtr);

If compiled with support for LTS, this method will set the task's local storage pointer.

void *getLtsPointer();

If compiled with support for LTS, this method will return reference to the task's local storage.

Note: the value returned has type (void *), and needs to be re-cast into appropriate pointer type. Please refer to example sketches for implementation options.

TASK SCHEDULER:

CREATION:

Scheduler()

Default constructor.

Takes no parameters. Creates task scheduler with default parameters and an empty task queue.

void init()

Initializes the task queue and scheduler parameters, Executed as part of constructor, so don't need to be explicitly called after creation.

Note: be default (if compiled with _TASK_TIMECRITICAL enabled) scheduler is allowed to put processor to IDLE sleep mode. If this behavior was changed via allowSleep() method, inti() will NOT reset allow sleep particular parameter.

void addTask(Task& aTask)

Adds task aTask to the execution queue (or chain) of tasks by appending it to the end of the chain. If two tasks are scheduled for execution, the sequence will match the order in which tasks were appended to the chain. However, in reality, due to different timing of task execution, the actual order may be different.

Note: Currently, changing the execution sequence in a chain dynamically is not supported.

If you need to reorder the chain sequence – initialize the scheduler and re-add the tasks in a different order.

void deleteTask(Task& aTask)

Deletes task aTask from the execution chain. The chain of remaining tasks is linked together (i.e

if original task chain is 1 → 2 → 3 → 4, deleting 3 will result in 1 → 2 → 4).

Note: it is not required to delete a task from the chain. A disabled task will not be executed anyway, but you save a few microseconds per scheduling pass by deleting it, since it is not even considered for execution.

An example of proper use of this method would be running some sort of initialize task in the chain, and then deleting it from the chain since it only needs to run once.

void allowSleep(bool aState)

Available in API only if compiled with _TASK_TIMECRITICAL enabled. Controls whether scheduler is allowed (aState =true), or not (aState =false) to put processor into IDLE sleep mode in case not tasks are scheduled to run.

The default behavior of scheduler upon creation is to allow sleep mode.

void enableAll()

void disableAll()

enables and disables (respectively) all tasks in the chain. Convenient if your need to enable/disable majority of the tasks (i.e. disable all and then enable one).

Task& currentTask()

Returns reference to the task, currently executing via execute() loop OR for OnEnable and OnDisable methods, reference to the task being enabled or disabled.

This distinction is important because one task can activate the other, and OnEnable should be referring to the task being enabled, not being executed.

Could be used by callback methods to identify which Task actually invoked this callback method.

void* currentLts()

Returns pointer to Local Task Storage of the task, currently executing via execute() loop OR for OnEnable and OnDisable methods, task being enabled or disabled.

void execute()

Executes one scheduling pass, including end-of-pass sleep. This method is typically placed inside the loop() method of the sketch. Since execute exits after every pass, you can put additional statements after execute inside the loop()

bool isOverrun()

If library is compiled with _TASK_TIMECRITICAL enabled, this method returns true if currently invoked task has overrun its scheduled start time when it was invoked. Returns false if task has been invoked according to schedule.

STATUS REQUEST:

CREATION:

StatusRequest()

Default constructor.

Takes no parameters. Creates Status Request object, which is assigned a status of “completed” on creation.

void setWaiting(unsigned int aCount = 1)

Activates Status Request object. By default each object is set to wait on one event only, however, if aCount is supplied, Status Request can wait on multiple events. For instance, setWaiting(3) will wait on three signals. An example could be waiting for completion of measurements from 3 sensors.

bool signal(int aStatus)

Signals completion of the event to the Status Request object, and passes a completion code, which could be interrogated later.

Note: passing a negative status code to the status request object is considered reporting an error condition, and will complete the status request regardless of how many outstanding signals it is still waiting for.

Note: only the latest status code is kept.

bool signalComplete (int aStatus)

Signals completion of ALL events to the Status Request object, and passes a completion code, which could be interrogated later. The status request completes regardless of how many events it is still waiting on.

bool pending()

Returns true if status request is still waiting for event or events to happen.

bool completed ()

Returns true if status has completed.

int getStatus()

Returns the status code passed to the status request object by the signal() and signalComplete() methods.

Any positive number is considered a successful completion status.

A 0 (zero) is considered a default successful completion status.

Any negative number is considered an error code and unsuccessful completion of a request.

CONSTANTS:

TASK_SECOND (1000)

Task interval of 1 second

TASK_MINUTE (60000)

Task interval of 1 minute

TASK_HOUR (3600000)

Task interval of 1 hour

TASK_FOREVER (-1)

Task number of iterations for infinite number of iterations

TASK_ONCE (1)

Task single iteration

TASK_IMMEDIATE (0)

Task interval for immediate execution

IMPLEMENTATION SCENARIOS AND IDEAS:

EVENT DRIVEN PROGRAMMING

Each of the processes of your application becomes a separate and distinct programming area, which may or may not interact and control each other.

Example:

In a plant watering system you need to measure soil humidity, control pump and display the results

Each of the areas becomes a task:

Task tMeasure (TMEASURE_INTERVAL*SECOND, TASK_FOREVER, &measureCallback);
Task tWater (TWATER_INTERVAL*SECOND, RETRIES, &waterCallback);
Task tDisplay (TDISPLAY_INTERVAL*SECOND, TASK_FOREVER, &displayCallback);

Scheduler taskManager;

Further, once you turn on the pump, you keep it running for TWATER_INTERVAL interval and then turn it off. Turning off a pump is also a task which only needs to run once for every time the pump is turned on:

Task tWaterOff (WATERTIME*SECOND, TASK_ONCE, &waterOffCallback);

Example of the callback method:

void waterOffCallback() {
motorOff();
tWater.enableDelayed();
}

void waterCallback() {
if (tWater.getIterations()) {

// If this is not the last iteration = turn the pump on
motorOn();
tWaterOff.set(parameters.watertime * TASK_SECOND, TASK_ONCE, &waterOffCallback);
tWaterOff.enableDelayed();
return;
}

// We could not reach target humidity – something is wrong
motorOff;
taskManager.disableAll();
tError.enable();
}

Your sample setup() and loop() (partially) are as follows.

Note: please note that tWater is not activated during setup(). It is activated by tMeasure callback once the watering conditions are met.

void setup()

...

tWater.setIterations(parameters.retries);
tWaterOff.setInterval(parameters.watertime * SECOND);

taskManager.init();
taskManager.addTask(tMeasure);
taskManager.addTask(tDisplay);
taskManager.addTask(tWater);
taskManager.addTask(tWaterOff);

tMeasure.enable();
tDisplay.enable();

currentHumidity = measureHumidity();
}

void loop ()
{
taskManager.execute();
}

“NATIVE” SUPPORT FOR FINITE STATE MACHINE

Define “states” as callback method or methods. Each callback method executes activities specific to a “state” and then “transitions” to the next state by assigning next callback method to the task.

Transition from one state to the next is achieved by setting next callback method at the end of preceding one.

Note: do not call the next callback method explicitly. Yield to the scheduler, and let the scheduler take care of next iteration during the next pass. (Thus giving other tasks change to run their callback methods).

Example: Blinking LED 2 times a second could be achieved this way

Scheduler ts;

Task tLedBlinker (500, TASK_FOREVER, &ledOnCallback, &ts, true);

void ledOnCallback() {

turnLedOn();

tLedBlinker.setCallback(&ledOffCallback);

}

void ledOffCallback() {

turnLedOff();

tLedBlinker.setCallback(&ledOnCallback);

}

setup() {

}

loop () {

ts.execute();

}

Obviously the example is simple, but gives the idea of how the tasks could be used to go through states.

MULTIPLE POSSIBLE CALLBACKS FOR TASK

There may be a need to select an option for callback method based on certain criteria, or randomly.

You can achieve that by defining an array of callback method pointers and selecting one based on the criteria you need.

Example: when a robot detects an obstacle, it may go left, right backwards, etc. Each of the “directions” or “behaviors” are represented by a different callback methods.

Another example of using multiple callbacks:

You may need to “initialize” variables for a particular task.

In this case, define a tasks with two callbacks:

Task tWork (T_INTERVAL, TASK_FOREVER, &workCallbackInit);

…

void workCallbackInit() {

// do your initializationstuff here

// finally assigne the main callback method

tWork.setCallback(&workCallback);

}

void workCallback() {

// main callback method

…

}

The task will initialize during first execution pass and switch to “regular” callback execution starting with second pass. There is a delay between first and second passes of the task (scheduling period, if defined). In order to execute the second pass immediately after initialization first pass, change the above code like this:

void workCallbackInit() {

// do your initializationstuff here

// finally assigne the main callback method

tWork.setCallback(&workCallback);

tWork.enable();

}

The task will run initialization first, then immediately second pass, and then switch to processing at regular intervals starting with a third pass.

INTERRUP-DRIVEN EXECUTION SUPPORT

In case of interrupt-driven program flow, tasks could be scheduled to run once to request asynchronous execution (request), and then re-enabled (restarted) again with a different callback method to process the results.

Example: event driven distance calculation for ultrasonic pulses. EchoPin #6 triggers pin change interrupts on rising and falling edges to determine the length of ultrasonic pulse.

#include <DirectIO.h>
#include <TaskScheduler.h>
#include <PinChangeInt.h>

#define TRIGGERPIN 5
#define ECHOPIN 6

Output<TRIGGERPIN> pTrigger;
Input<ECHOPIN> pEcho;

Scheduler r;

Task tMeasure(TASK_SECOND, TASK_FOREVER, &measureCallback, &r, true);
Task tDisplay(TASK_SECOND, TASK_FOREVER, &displayCallback, &r, true);
Task tPing(TASK_IMMEDIATE, TASK_ONCE, &pingCalcCallback, &r, false);

volatile bool pulseBusy = false;
volatile bool pulseTimeout = false;
volatile unsigned long pulseStart = 0;
volatile unsigned long pulseStop = 0;
volatile unsigned long pingDistance = 0;

void pingTrigger(unsigned long aTimeout) {
if (pulseBusy) return; // do not trigger if in the middle of a pulse
if (pEcho == HIGH) return; // do not trigger if ECHO pin is high

pulseBusy = true;
pulseTimeout = false;

pTrigger = LOW;
delayMicroseconds(4);
pTrigger = HIGH;

tPing.setInterval (aTimeout);

delayMicroseconds(10);
pTrigger = LOW;

tPing.restartDelayed(); // timeout countdown starts now

// will start the pulse clock on the rising edge of ECHO pin

PCintPort::attachInterrupt(ECHOPIN, &pingStartClock, RISING);
}

// Start clock on the rising edge of the ultrasonic pulse
void pingStartClock() {
pulseStart = micros();
PCintPort::detachInterrupt(ECHOPIN); // not sure this is necessary
PCintPort::attachInterrupt(ECHOPIN, &pingStopClock, FALLING);
tPing.restartDelayed();
}

// Stop clock on the falling edge of the ultrasonic pulse
void pingStopClock() {
pulseStop = micros();
PcintPort::detachInterrupt(ECHOPIN);

pingDistance = pulseStop - pulseStart;
pulseBusy = false;
tPing.disable(); // disable timeout
}

// Stop clock because of the timeout – the wave did not return
void pingCalcCallback() {
if (pulseBusy) {
pingStopClock();
}
pulseTimeout = true;
}

// Initial measure callback sets the trigger
void measureCallback() {
if (pulseBusy) { // already measuring, try again
tMeasure.enable();
return;
}
pingTrigger(30); // 30 milliseconds or max range of ~5.1 meters
tMeasure.setCallback(&measureCallbackWait);
}

// Wait for the measurement to
void measureCallbackWait() {
if (pulseBusy) return;
tMeasure.setCallback(&measureCallback);
}

bool state = true;

void displayCallback() {
char d[256];

unsigned long cm = pingDistance * 17 / 100; // cm

snprintf(d, 256, "pulseStart = %8lu\tpulseStop=%8lu\tdistance, cm=%8lu", pulseStart, pulseStop, cm);
Serial.println(d);

}

void setup() {
// put your setup code here, to run once:

Serial.begin(115200);

pTrigger = LOW;
pEcho = LOW;

}

void loop() {
// put your main code here, to run repeatedly:
r.execute();
}

USING ONENABLE AND ONDISBALE METHODS

Consider a task to flash onboard LED for 5 seconds with random frequency. Task should be repeated every 30 seconds indefinitely. Since frequency is random, there are two challenges:

We need to make sure LED is turned OFF at the last iteration
We need to calculate random frequency every time

Below is the implementation using TaskScheduler

#define _TASK_SLEEP_ON_IDLE_RUN

#include <TaskScheduler.h>

#define LEDPIN 13

Scheduler ts;

Task tWrapper(30000, TASK_FOREVER, &WrapperCallback, &ts, true);

Task tBlink(5000, TASK_ONCE, NULL, &ts, false, &BlinkOnEnable, &BlinkOnDisable);

Task tLED(TASK_IMMEDIATE, TASK_FOREVER, NULL, &ts, false, NULL, &LEDOff);

void WrapperCallback() {

Serial.println("In WrapperCallback");

tBlink.restartDelayed(); // LED blinking is initiated

//every 30 seconds for 5 seconds

}

// Upon being enabled, tBlink will define the parameters

// and enable LED blinking task, which actually controls

// the hardware (LED in this example)

bool BlinkOnEnable() {

Serial.println("In BlinkOnEnable");

tLED.setInterval( 500 + random(501) );

tLED.setCallback( &LEDOn);

tLED.enable();

return true; // Task should be enabled

}

// tBlink does not really need a callback method

// since it just waits for 5 seconds for the first

// and only iteration to occur. Once the iteration

// takes place, tBlink is disabled by the Scheduler,

// thus executing its OnDisable method below.

void BlinkOnDisable() {

Serial.println("In BlinkOnDisable");

tLED.disable();

}

void LEDOn () {

Serial.println("In LEDOn");

digitalWrite(LEDPIN, HIGH);

tLED.setCallback( &LEDOff);

}

void LEDOff () {

Serial.println("In LEDOff");

digitalWrite(LEDPIN, LOW);

tLED.setCallback( &LEDOn);

}

// Note that LEDOff method serves as OnDisable method

// to make sure the LED is turned off when the tBlink

// task finishes (or disabled ahead of time)

void setup() {

Serial.begin(115200);

pinMode(LEDPIN, OUTPUT);

}

void loop() {

// put your main code here, to run repeatedly:

ts.execute();

}

USING STATUS REQUEST OBJECTS

This test emulates querying 3 sensors once every 10 seconds, each could respond with a different delay (ultrasonic sensors for instance) and printing a min value of the three when all three have reported their values.

The overall timeout of 1 second is setup as well.

An error message needs to be printed if a timeout occurred instead of a value.

#define _TASK_SLEEP_ON_IDLE_RUN

#define _TASK_STATUS_REQUEST

#include <TaskScheduler.h>

StatusRequest measure;

Scheduler ts;

Task tCycle(10000, TASK_FOREVER, &CycleCallback, &ts, true);

Task tMeasure(TASK_SECOND, TASK_ONCE, &MeasureCallback, &ts, false, &MeasureEnable, &MeasureDisable);

Task tCalculate(&CalcCallback, &ts);

Task tSensor1(TASK_IMMEDIATE, TASK_ONCE, &S1Callback, &ts, false, &S1Enable);

Task tSensor2(TASK_IMMEDIATE, TASK_ONCE, &S2Callback, &ts, false, &S2Enable);

Task tSensor3(TASK_IMMEDIATE, TASK_ONCE, &S3Callback, &ts, false, &S3Enable);

long distance, d1, d2, d3;

void CycleCallback() {

Serial.println("CycleCallback: Initiating measurement cycle every 10 seconds");

tMeasure.restartDelayed();

}

bool MeasureEnable() {

Serial.println("MeasureEnable: Activating sensors");

distance = 0;

measure.setWaiting(3); // Set the StatusRequest to wait for 3 signals.

tCalculate.waitFor(&measure);

tSensor1.restart();

tSensor2.restart();

tSensor3.restart();

return true;

}

void MeasureCallback() {

Serial.println("MeasureCallback: Invoked by calculate task or one second later");

if (measure.pending()) {

tCalculate.disable();

measure.signalComplete(-1); // signal error

Serial.println("MeasureCallback: Timeout!");

}

else {

Serial.print("MeasureCallback: Min distance=");Serial.println(distance);

}

void MeasureDisable() {

Serial.println("MeasureDisable: Cleaning up");

tSensor1.disable();

tSensor2.disable();

tSensor3.disable();

}

void CalcCallback() {

Serial.println("CalcCallback: calculating");

distance = -1;

if ( measure.getStatus() >= 0) { // only calculate if statusrequest ended successfully

distance = d1 < d2 ? d1 : d2;

distance = d3 < distance ? d3 : distance;

tMeasure.forceNextIteration();

}

/** Simulation code for sensor 1

* ----------------------------

bool S1Enable() {

Serial.print("S1Enable: Triggering sensor1. Delay=");

tSensor1.setInterval( random(1200) ); // Simulating sensor delay, which could go over 1 second and cause timeout

d1 = 0;

Serial.println( tSensor1.getInterval() );

return true;

}

void S1Callback() {

Serial.print("S1Callback: Emulating measurement. d1=");

d1 = random(501); // pick a value from 0 to 500 "centimeters" simulating a measurement

measure.signal();

Serial.println(d1);

}

/** Simulation code for sensor 2

* ----------------------------

bool S2Enable() {

Serial.print("S2Enable: Triggering sensor2. Delay=");

tSensor2.setInterval( random(1200) ); // Simulating sensor delay, which could go over 1 second and cause timeout

d2 = 0;

Serial.println( tSensor2.getInterval() );

return true;

}

void S2Callback() {

Serial.print("S2Callback: Emulating measurement. d2=");

d2 = random(501); // pick a value from 0 to 500 "centimeters" simulating a measurement

measure.signal();

Serial.println(d2);

}

/** Simulation code for sensor 3

* ----------------------------

bool S3Enable() {

Serial.print("S3Enable: Triggering sensor3. Delay=");

tSensor3.setInterval( random(1200) ); // Simulating sensor delay, which could go over 1 second and cause timeout

d3 = 0;

Serial.println( tSensor3.getInterval() );

return true;

}

void S3Callback() {

Serial.print("S3Callback: Emulating measurement. d3=");

d3 = random(501); // pick a value from 0 to 500 "centimeters" simulating a measurement

measure.signal();

Serial.println(d3);

}

/** Main Arduino code

* Not much is left here - everything is taken care of by the framework

void setup() {

Serial.begin(115200);

Serial.println("TaskScheduler StatusRequest Sensor Emulation Test. Complex Test.");

randomSeed(analogRead(A1)+millis());

}

void loop() {

ts.execute();

}

USING LOCAL TASK STORAGE POINTER

Tasks can store a pointer to specific variable, structure or array, which represents variables specific for a particular task. This may be needed if you plan to use same callback method for multiple tasks.

Consider a scenario where you have several sensors of the same type. The actual process of triggering measurement and collecting information is identical. The only difference is the sensor address and a variable for storing the results.

In this case each of the tasks, which performs measurement will utilize the same callback methods. The only difference will be the variables (specific for each of the sensor).

Let's define a sensor data structure and declare a couple of variables (for 2 sensors for instance)

typedef struct {

unsigned int address;

unsigned long distance;

} sensor_data;

sensor_data s1, s2;

Two separate tasks are running to collect sensor data.

(Note that both tasks refer to the same callback methods)

Scheduler ts;

Task t1(100, TASK_FOREVER, &Measure, &ts, false, &MeasureOn);

Task t2(100, TASK_FOREVER, &Measure, &ts, false, &MeasureOn);

Assign pointers to the respective variables in the setup() method:

void setup() {

…

t1.setLtsPointer(&s1);

t2.setLtsPointer(&s2);

…

}

Obtain reference to specific sensor_data structure inside the common callback method:

void Measure() {

Task& T = ts.currentTask();

Sensor_data& V = *((sensor_data*) T.getLtsPointer());

// For t1, V will be pointing at s1

// For t2, V will be pointing at s2

// Alternatively use the Scheduler method:

Sensor_data& V1 = *((sensor_data*) ts.currentLts());

…

V.distance = <calculate your values here>;

}

FUTHER INFROMATION

Please refer to examples, provided with TaskScheduler package for further information and implementation options.

Real time examples of TaskScheduler are available here: