Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists