Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#58 Couple of small feature requests

Robert Turner

Hi Richard,
I'm a long time FreeRTOS user and run practically all my projects in it. Over the years I've got two patches that I routinely put in tasks.c with every new FreeRTOS release and I'd like to see if they're worth adding to the trunk to both prevent me having to patch each time and also for others to benefit from.
The two patches consist of:
1) Being able to add arbitrary data to each TCB. Specifically I always use this for saving the newlib reent structs. It's extremely similar to configUSE_APPLICATION_TASK_TAG except that I can define an arbitrary data type (eg some struct) in FreeRTOSConfig.h.
I typically implement it as a:

2) Many small changes to allow configMAX_TASK_NAME_LEN to be zero. Of course I only use this on tiny (low ram & flash) devices, but when mem is extremely scarce it's invaluable.
The code implications are that for a size of zero I don't even store a task name in the TCB.

Thoughts how to either address these in the existing release or integrating these would be greatly appreciated.


  • Richard

    I would be grateful if you could elaborate on these a little, because they should be easy to implement if they cannot be achieved already:

    > Being able to add arbitrary data to each TCB

    You mention the configUSE_APPLICATION_TASK_TAG functionality, so you are obviously aware of it. It is not obvious to me why you can't use it though. I would have thought you could malloc the structure you require, then use the set application task tag function to have the tag (which is basically a pointer) to point to the structure. You can then use the get equivalent to switch the structure being sued during a context switch.

    > Many small changes to allow configMAX_TASK_NAME_LEN to be zero

    Ideally the name would just be a char* rather than an array of characters. The original thinking was to copy the name into the TCB in case the character string used to set the name in the first place was not persistent (i.e. it was allocated on the stack, or a temporary buffer, etc.).

    I believe the size of the array can be set to 1, so just holding the null terminator. That would only then require one byte extra per task, so extremely low.

    If configMAX_TASK_NAME_LEN == 1, then the strncpy() call is not compiled in, hopefully that reduces the ROM footprint by not bringing in additional library functions, but the NULL terminator is till put in so anything that tries to read the name (including kernel away debuggers) does not cause a crash. Removing the name altogether would I think result in more than a small patch, as it is used in a few places (stack overflow hook, task stats, run-time stats, etc.). So how do you go about removing the name?


  • Robert Turner
    Robert Turner

    Thanks for the comments Richard.
    I have added my arbitrary data using the APPLICATION_TASK_TAG as suggested. There is still, however, some functionality that I have added without editing tasks.c by simply #including tasks.c into a tasks_wrapper.c. The additional functionality includes:
    - "pdTASK_HOOK_CODE xTaskGetApplicationTaskTagFromISR( xTaskHandle xTask )". Pretty self explanatory.
    - "xMPU_SETTINGS * xTaskGetMPURegions( xTaskHandle xTask )"
    And I've also hijacked traceTASK_SWITCH_IN to insert some additional code during context switch.
    I've found wrapping tasks.c with a wrapper very powerful as it's the only way I can add task-specific code which has access to the tskTCB struct info

    Regarding the MAX_TASK_NAME_LEN, that's fine. A task len of 1 suffices. Thanks