You had made this comment - wondering if it was looked into or not:
Please add your request to the feature request tracker in sourceforge.
It might be possible for the kernel to call xTaskCreate() on the task again, effectively setting it back to its initial conditions using the same TCB and stack.
I have a need for something like this - to be able to 'reset' or 'restart' a task. I suppose I could kill it and recreate it - but it would be convenient to restart it.
This has not been done yet as it is actually quite complex - although the new ability to create tasks using statically allocated memory may make it simpler.
Hmmm. OK. I was thinking about just saving off the TCB and orig stack and restoring it - maybe it isn't that easy.
Could a region be defined in heap5.c for a particular task to make this easier?
Do you have a procedure for how to try this with the statically allocated tasks? Maybe the easiest is to 2X the memory at task creation and restore the TCB and stack at exit if the task is to be reset or just rerun the task creation steps at exit using the original TCB and stack pointers.
I don't think this can be done in a portable way very easily. To truly
restart a task (so you get the parameter passed in again, the thread
local storage was cleared, etc.) you would need an API function that:
1) Deletes the existing task to ensure it is not referenced from any
state lists or other objects. The easiest way of doing that would be to
2) Create a new task so the TCB was re-initialised, the initial stack of
the task was set back to its original state, the register values were
set back to their initial state, etc. The easiest way of doing that
would be to call xTaskCreate() again - however you would not know what
the initial value of the task parameter was.
With dynamically allocated memory this is tricky because once the task
has been deleted there is no stack, so xTaskCreate() could not be
called. However, with statically allocated memory that is not the case,
the stack memory can be borrowed between the delete and subsequent
re-creation of the task.
In fact, probably the easiest way of doing this would be to allow the
RTOS daemon task/timer service task to perform these actions, rather
than have the task do it itself. That way you could also do it with
dynamic memory allocation.
However, maybe if you really want a task to restart the simplest thing
to do would be to have the task jump back up to the start of its
implementing function at the appropriate time? You would have to
re-initialise any stack variables manually, as the function prologue
code would not execute.
So, maybe a taskReset 'hook' can be added?