Some of us are old/wise/experienced/paranoid enough to embed resource use monitoring in our applications. Especially stack use for each task and (on CortexM or MCU with separate stack for ISRs) MSP/ISR stack. I added MSP/ISR stack use checking to the port, and tried to use uxTaskGetSystemState for the task stacks - and of course found that the biggest memory pig was… uxTaskGetSystemState. This because uxTaskGetSystemState wants a large structure for each task pre-allocated. Other folks have complained about this in past…
Change
I factored out the multi-list task iteration bit of uxTaskGetSystemState into an iterator as follows:
/* For each task, call pxCallbackFunction with the task's TaskStatus_t */
UBaseType_t uxTaskCallForEachTask(
TaskStatusCallbackFunction_t pxCallbackFunction,
void * pvCallbackContext,
configRUN_TIME_COUNTER_TYPE * const pulTotalRunTime ) PRIVILEGED_FUNCTION;
This allows me to go through the task list and snapshot {name, stack size, stack unused} for the diagnostic logging of my device, with only the 72-byte TaskStatus_t on the stack (as opposed to >1kb array formerly required).
uxTaskGetSystemState now uses the above iterator.
So… Is anybody interested in a pull-request?
It is all Doxygen-commented and tested of course.
I am trying to understand your proposal. If I understand correctly, you are trying to propose an additional implementation of uxTaskGetSystemState which calls the user provided callback for each task instead of filling information about all the tasks in one large array:
UBaseType_t uxTaskGetSystemStateWithCallback( TaskStatus_t * pxTaskStatus,
TaskStatusCallbackFunction_t pxCallbackFunction,
void * pvCallbackContext,
configRUN_TIME_COUNTER_TYPE * const pulTotalRunTime )
{
for task in taskLists:
Fill *pxTaskStatus with task info
Call pxCallbackFunction with pxTaskStatus and pvCallbackContext
Update *pulTotalRunTime
}
Is that correct? If yes, this is a good addition and backward compatible. Please raise a PR.
No, I added a public iterator uxTaskCallForEachTask, and re-implemented uxTaskGetSystemState using the iterator (preserving the existing public interface so as not to disrupt current users). Not an additional implementation of uxTaskGetSystemState - a replacement. Sorry if I wasn’t clear! You still want a pull-request?
I will note that one issue with uxTakCallForEachTask is that by necessity the task information will not be at the some point of time if the callback function tries to output results as it goes, and the need for a buffer to store the data all for one point of time has been just been moved.
In my own code the usage of vTaskGetSystemState doesn’t use a lot of STACK, as I create that buffer on the heap, where that memory can be used by other tasks at other times for similar non-critical memory usages.
Note too, you can inject the code for your uxTaskCallForEachTask into task.c by use of the file freertos_tasks_c_additions.h which you can create in your project, on the include directory list, and defining configINCLUDE_FREERTOS_TASK_C_ADDITIONS_H to 1 in your freertosconfig.h file.
This way you can publish it as an addon and let people test it and see how useful it is before it needs to be merged into the kernel.