Task Scheduler – cooperative multitasking for Arduino microcontrollers

Version 1.8.0: 2015-10-15


OVERVIEW:

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

  1. Periodic task execution (with dynamic execution period in milliseconds)

  2. Number of iterations (n times)

  3. Execution of tasks in predefined sequence

  4. Dynamic change of task execution parameters (frequency, number of iterations, callback function)

  5. Power saving via entering IDLE sleep mode between tasks are scheduled to run

  6. Support for task invocation via Status Request object


TASK:

“Task” is a container concept that links together:

  1. Execution interval

  2. Execution event (Status Request)

  3. Number of execution iterations

  4. Piece of code performing task activities (callback functions)


Tasks are linked into execution chains, which are processed by the “Scheduler” in the order they are linked.


Each task performs its function via callback function. Scheduler calls Task’s callback function periodically until task is disabled or task runs out of iterations. In addition to “regular” callback, two methods could be enabled for each task: a callback function invoked once when task is enabled, and a callback function invoked once when the task is disabled. Those two special methods allows task to properly initiate themselves for execution and clean-up after execution is over.


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


“Scheduler” is executing Tasks' callback functions 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() function to run. This a “scheduling pass”.


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 functions. This is done to avoid repetitive empty 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 callback execution.


Below is the flowchart of a Task lifecycle:


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() function 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 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 examples at the end of this document.


COMPILE PARAMETERS:

This library could be compiled with several options.

These parameters must be defined before inclusion of the library header file into the 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() function. If getOverrun returns a negative value, this Task’s next execution time is in the past, and task is behind schedule. This most probably means that either task’s callback function runtime is too long, or the execution interval is too short (then schedule is too aggressive).

A positive value indicates that task is on schedule, and callback functions 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 functions were activated during pass. IDLE state is interrupted by timers once every 1 ms. 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.

NOTE: above parameters are DISABLED by default, and need to be explicitly enabled.




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 function defined, so no 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> function on every pass.

  1. aInterval is in milliseconds (default = 0)

  2. 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.

  3. aCallback is a pointer to a void callback function without parameters (default = NULL)

  4. 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)

  5. aEnable – optional. Value of true will create task enabled. (default = false)

  6. aOnEnable is a pointer to a bool callback function without parameters, invoked when task is enabled. If OnEnable function returns true, task is enabled. If OnEnable function return false, task remains disabled (default = NULL)

  7. aOnDisable is a pointer to a void callback function 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.

Enabled task is scheduled for execution immediately. Enable tasks with delay (standard execution interval or specific execution interval) in order to defer first run of the task.


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.


INFORMATION

The following 3 “getter” functions 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 functions 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 function returns number of milliseconds between next execution time and current time. If the value is negative, the task is overrun 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 function has been invoked since the last time a task was enabled.

NOTE: The runCounter value is incremented before callback function is invoked. If a task is checking the runCounter value within its callback function, 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 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: enable() invokes task’s OnEnable method (if not NULL), 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.


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.


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 a delay (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 function will re-enable the task, set the number of iterations back to when the task was created and and schedule the task for execution as soon as possible.


void restartDelayed (unsigned long aDelay);


Same as restart() function, 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. OnDisable is invoked only if task was enabled. 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 function call.

Note: OnEnable and OnDisable parameters can be omitted. In that case they will be assigned to NULL and not called.


Next five “setter” functions 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 function 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 function 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.


void waitFor(StatusRequest* aStatusRequest);


If compiled with support for Status Requests, this method makes task wait for the completion of aStatusRequest event.

waitFor() sets tasks interval to 0 (zero) for immediate execution when event happens, and also sets the number of iterations to 1.

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



StatusRequest* getStatusRequest()

Returns a StatusReqeust object this Task was waiting on.





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() function, 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 function 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. Could be used by callback functions to identify which of the Tasks invoked callback function.


void execute()


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




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)

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.




IMPLEMENTATION SCENARIOS AND IDEAS:


  1. 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, -1, &measureCallback);
Task tWater (TWATER_INTERVAL*SECOND, RETRIES, &waterCallback);
Task tDisplay (TDISPLAY_INTERVAL*SECOND, -1, &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, 1, &waterOffCallback);

Example of the callback function:


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


or


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

// If this is not the last iteration = turn the pump on
motorOn();
tWaterOff.set(parameters.watertime * SECOND, 1, &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.


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();
}


  1. NATIVE” SUPPORT FOR FINITE STATE MACHINE


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

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

Note: do not call the next callback function. Let the schedule take care of that during the next pass. (Thus letting other tasks run).


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


Task tLedBlinker (500, -1, &ledOnCallback);

Scheduler taskManager;


void ledOnCallback() {

turnLedOn();

tLedBlinker.setCallback(&ledOffCallback);

}


void ledOffCallback() {

turnLedOff();

tLedBlinker.setCallback(&ledOnCallback);

}


setup() {

taskManager.init();
taskManager.addTask(tLedBlinker);

tLedBlinker.enable();

}


loop () {

taskManager.execute();

}

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




  1. MULTIPLE POSSIBLE CALLBACKS FOR TASK


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

You can achieve that by defining an array of callback function 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 function.


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, -1, &workCallbackInit);


void workCallbackInit() {

// do your initializationstuff here

// finally assigne the main callback function

tWork.setCallback(&workCallback);

}


void workCallback() {

// main callback function

}


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 function

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.


  1. 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 function 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(1000, -1, &measureCallback, &r, true);
Task tDisplay(1000, -1, &displayCallback, &r, true);
Task tPing(0, 1, &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();
}

  1. 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:

    1. We need to make sure LED is turned OFF at the last iteration

    2. 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, -1, &WrapperCallback, &ts, true);

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

Task tLED(0, -1, 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 function

// 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();

}




  1. 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, -1, &CycleCallback, &ts, true);

Task tMeasure(1000, 1, &MeasureCallback, &ts, false, &MeasureEnable, &MeasureDisable);

Task tCalculate(&CalcCallback, &ts);

Task tSensor1(0, 1, &S1Callback, &ts, false, &S1Enable);

Task tSensor2(0, 1, &S2Callback, &ts, false, &S2Enable);

Task tSensor3(0, 1, &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();


}