hermarcel wrote on Monday, June 17, 2013:

Would it be possible to extend the FreeRTOS with a TaskRestart() function? It can, of course, be done by calling vTaskDelete() and xTaskCreate() but a dedicated function would not need to first free and then re-allocate the memory. Heap_1.c would then still be usable.

woops_ wrote on Monday, June 17, 2013:

Can you use setjmp() and longjmp() in your task to do this?

hermarcel wrote on Monday, June 17, 2013:

Probably. I could even breakout of the task loop and goto the beginning of the task function. But it would be nice if it could be done from another task.

rtel wrote on Monday, June 17, 2013:

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.


hermarcel wrote on Monday, June 17, 2013:

Done. :slight_smile:

richard_damon wrote on Monday, June 17, 2013:

I would add that I find very little use for a task to delete/restart another, and it is almost always a better way to make a bigger mess than to clean things up. The problem is that, unlike processes on “big” operating systems, there is very little clean up that FreeRTOS does (or even can do). Resources taken by the task are NOT returned.  Semaphores or Mutexes (I believe) taken are not returned

Normally the desire for reason for wanting another task to kill a given task is that there is a concern that the task might have “crashed”, but if that is really the case, the whole system state is really suspect, so the best thing to do is a full system restart. (perhaps a system with memory protection might be an exception).

I would think the more robust method would be for the task, when it is done with what it can do, is to suspend/block itself, and when another task has something for it to do that task resumes/unblocks the task.  If you want to have a way to stop the task in the middle of its operation, it is easy enough to create a global flag that tasks can set to tell the task to abort its actions, and have the task check this frequently at points where it is safe to do so.

hermarcel wrote on Tuesday, June 18, 2013:

You are right. I totally overlooked the cleanup that will not take place. I think it is better to drop this request.