Hey,

I have a question...

Is it possible to reset a task?

For example:

if i have the task like this

static portTASK_FUNCTION( vLightsTask, pvParameters )
{

initSomeThings();<----- RESART HERE

for(;;)
{
switch(light_algorithm)
{
CASE (flash_fast):
TurnLightsOn();
vTaskDelay(1000);<-------------- HERE
TurnLightsOff();
vTaskDelay(1000);
break;
CASE (flash_slow)
TurnLightsOn();
vTaskDelay(9000);
TurnLightsOff();
vTaskDelay(9000);
break;
}
}
}


This task is running and it currently is a delay.

From another function i want to be able to resart the task, so it would remove it from the delay and start over.

I guess i could delete the task and then re-create it but i thought this might take too long, is there another way

If i am not making sense let me know and i will try and explain.

Cheers

Murray

Just some more background on what i am doing.

I have 1 task that implements about 8 different LED flashing algorithms.

I have a global varible that indicated that algorithm is currently set.

This varible is check in the task and then the LED algorithm is executed.

I have a function that is called to set the current algorithm,
If this function is called i want the task to stop what it is doing and start the new algorithm.

Currently it has to wait 1 cycle before it starts the new one.

Would i be better looking a using co-routines, 1 for each LED algorithm.

Cheers

Hello,

Have you looked at the API functions:

vTaskSuspend() and vTaskResume()?

Can't you do what you want with these?
There's also a tickHook() that can
be implemented.

HTH,
John W.

How about, instead of blocking using a delay, block on a queue read. Then if you want to change algorithms during the delay you wake the task by posting to the queue. The task recognises it has been woken before the end of the delay by the xQueueRead return value.

You could even get rid of the global variable then and post the algorithm that should be run on the queue.

yeah the suspend and resume doesn't do what i want. IF i suspend the task, then resume it, it contines from where it was, thus still executing the complete cycle.

The queue read sounds like a possibility. I will have a think about that a little more. Thanks