FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2014 Threads] handle based API call to retrieve (void *pvParameters) from the active TCB.Posted by markwrichardson on September 3, 2014 This was touched on during an old thread about retrieving the process name.
https://sourceforge.net/p/freertos/discussion/382005/thread/576a1660/
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.
handle based API call to retrieve (void *pvParameters) from the active TCB.Posted by markwrichardson on September 3, 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.
Thanks
Mark
P.S. - I get obsessive about byte counts sometimes . . .
handle based API call to retrieve (void *pvParameters) from the active TCB.Posted by rtel on September 4, 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 ?).
Regards.
handle based API call to retrieve (void *pvParameters) from the active TCB.Posted by markwrichardson on September 4, 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.
handle based API call to retrieve (void *pvParameters) from the active TCB.Posted by markwrichardson on 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|