handle based API call to retrieve (void *pvParameters) from the active TCB.

markwrichardson wrote on Wednesday, September 03, 2014:

This was touched on during an old thread about retrieving the process name.

I see that there is a facility for a Task Tag API to be added to a task, however it seems more efficient to have an API call to retrieve the parameters value from the running task’s TCB. With this I could place a pointer to a housekeeping structure within the otherwise unused parameter location during task creation.

I could make one for myself based on the name retrieval, but I think it would be a reasonable addition to the API.

In my case, I’m using FreeRTOS as a foreman for a group of networked modules allowing multiple simultaneous jobs and a command-line user interface.

markwrichardson wrote on Wednesday, September 03, 2014:

Exploring a bit further, I see that the parameter value is not saved in the TCB structure past the execution of the task function, although it is at the top of the stack for that task.

If you plan to continue storing the parameter value in this way, an API would hide the details of the stack implementation.

If you think the Task Tag feature is equally efficient, I can easily use that instead.


P.S. - I get obsessive about byte counts sometimes . . .

rtel wrote on Thursday, September 04, 2014:

P.S. - I get obsessive about byte counts sometimes . . .

I spend my life obsessing about it.

I think it is unlikely we would save the parameter anywhere other than the stack as it could prove wasteful for systems/tasks that don’t make use of it. When it is on the stack it will get popped from the stack - potentially to nowhere if it is not used (and compiler optimisation is on), and so not use any RAM space (maybe ?).


markwrichardson wrote on Thursday, September 04, 2014:

I looked at a few other ports besides mine and see that pvParameters is put in at the top of the stack initially for each task, so it is always stored for the life of the task. Since it is always on the stack, I had hoped a named function could be added to retrieve it.

I’ll just add the function to my PORT.C so I don’t have to worry RTOS upgrades in the future.

markwrichardson wrote on Wednesday, September 10, 2014:

After my superficial thoughts above, I see that it’s better just to use the vTaskSetApplicationTaskTag feature.

There is too much dependency on private implementation details to create an alternative using the base of the stack to store and subsequently retrieve the pvParameters value. Plus, that code is longer than the code for the supplied function.

It was an interesting study of stack and TCB details.
It started because I have several tasks running and many generic functions that call subfuctions who need to know which thread called them.