Hi Neil
uTaskerMonoTimer( TASK_SAMPLE, (DELAY_LIMIT)(0.25*SEC), 0 );
This is a special case due to the fact that the event is 0. This has the effect of adjusting the repetitive rate of the task TASK_SAMPLE. Effectively it will wake the task (without an event, not requiring an input queue and therefore not requiring a read) after 0.25s. The task will then be scheduled every further 0.25s. By calling
uTaskerMonoTimer( OWN_TASK, 0, 0 ); in the task itself it can however stop the repetitive scheduling and so behave like a single-shot timer.
Note that a suitable configuration for this task is:
{ "Sample", fnSampleTask, NO_QUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},
It needs a timer but doesn't need a queue.
The case is different if the event has a non-zero value. In this case the event is sent to the task when the timer fires and so the task needs an input queue to be able to receive it. In this case it should read the input so that the queue doesn't get full after several events. This means that the receiving task can handle different timer events and know exactly which timer it is.
However a non-zero event can also be sent to a task without an input queue! In this case it will try to send the event to the task's input queue but will fail (this is not a problem, it just doesn't find the task's queue and ignores it). The effect is that the task is still scheduled and so this can also be used for a simple task without input queue which only responds to one known event.
This gives you several possibilities. If you don't have a queue and don't need one it is in fact simplest to send a dummy (non-zero) event so that it will result in a single-shot timer. If you prefer a periodic timer then the zero event is the method to use.
Regards
Mark