vTaskGetRunTimeStats() for CPU usage in FreeRTOS - Time & Space Complexity
We want to understand how the time to gather CPU usage stats grows as the number of tasks increases.
How does the function's work change when there are more tasks to check?
Analyze the time complexity of the following code snippet.
void vTaskGetRunTimeStats( char *pcWriteBuffer ) {
TaskStatus_t *pxTaskStatusArray;
UBaseType_t uxArraySize, x;
uxArraySize = uxTaskGetNumberOfTasks();
pxTaskStatusArray = pvPortMalloc( uxArraySize * sizeof( TaskStatus_t ) );
uxArraySize = uxTaskGetSystemState( pxTaskStatusArray, uxArraySize, NULL );
for( x = 0; x < uxArraySize; x++ ) {
sprintf( pcWriteBuffer, "%s %lu\n", pxTaskStatusArray[ x ].pcTaskName, pxTaskStatusArray[ x ].ulRunTimeCounter );
pcWriteBuffer += strlen( pcWriteBuffer );
}
vPortFree( pxTaskStatusArray );
}
This code collects CPU usage stats for all tasks and writes them into a buffer.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The for-loop that goes through each task to write its stats.
- How many times: Once for each task, so as many times as there are tasks.
As the number of tasks grows, the function spends more time writing stats for each one.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 tasks | About 10 writes to the buffer |
| 100 tasks | About 100 writes to the buffer |
| 1000 tasks | About 1000 writes to the buffer |
Pattern observation: The work grows directly with the number of tasks.
Time Complexity: O(n)
This means the time to get CPU stats grows in a straight line as tasks increase.
[X] Wrong: "The function runs in constant time no matter how many tasks there are."
[OK] Correct: The function must look at each task to get its stats, so more tasks mean more work.
Understanding how functions scale with input size helps you write efficient code and explain your reasoning clearly.
"What if the function also sorted the tasks by CPU usage before writing? How would the time complexity change?"
Practice
vTaskGetRunTimeStats() function in FreeRTOS?Solution
Step 1: Understand the function's role
vTaskGetRunTimeStats()is designed to collect and display CPU usage statistics for each task in FreeRTOS.Step 2: Compare options with function purpose
Options A, B, and C relate to task management but not CPU usage reporting, which is the key role ofvTaskGetRunTimeStats().Final Answer:
To display the CPU usage time of each task -> Option DQuick Check:
Function purpose = CPU usage display [OK]
- Confusing it with task creation or deletion functions
- Thinking it suspends tasks instead of reporting stats
- Assuming it modifies task priorities
vTaskGetRunTimeStats() to store the stats in a buffer named buffer?Solution
Step 1: Check function parameter type
vTaskGetRunTimeStats()expects a pointer to a char array (string buffer), so passing the buffer name directly is correct.Step 2: Analyze each option's syntax
vTaskGetRunTimeStats(buffer); passes the buffer correctly. vTaskGetRunTimeStats(&buffer); passes address of buffer pointer (wrong). vTaskGetRunTimeStats(buffer[]); uses invalid syntax. vTaskGetRunTimeStats(*buffer); dereferences buffer incorrectly.Final Answer:
vTaskGetRunTimeStats(buffer); -> Option AQuick Check:
Pass buffer name directly [OK]
- Using &buffer which is wrong for arrays
- Adding [] inside function call
- Dereferencing buffer pointer incorrectly
statsBuffer?
char statsBuffer[100];
vTaskGetRunTimeStats(statsBuffer);
printf("%s", statsBuffer);
Assuming two tasks "TaskA" and "TaskB" run and TaskA used 70% CPU, TaskB used 30%.Solution
Step 1: Understand output format of vTaskGetRunTimeStats()
The function outputs CPU usage as run time counter ticks, not percentages. If TaskA used 70% CPU, it might show 7000 ticks and TaskB 3000 ticks (assuming 10000 total ticks).Step 2: Match options with expected output
TaskA 7000 TaskB 3000 shows usage in ticks (7000 and 3000), matching expected output. Options B, C, and D show percentages or smaller numbers, which are not the direct output format.Final Answer:
TaskA 7000 TaskB 3000 -> Option CQuick Check:
Output shows ticks, not percentages [OK]
- Assuming output shows percentages directly
- Confusing ticks with smaller numbers
- Expecting formatted percentages in output
vTaskGetRunTimeStats(statsBuffer); but the output is empty. What is the most likely cause?Solution
Step 1: Identify prerequisites for run time stats
Run time stats must be enabled in FreeRTOSConfig.h (configGENERATE_RUN_TIME_STATS set to 1) forvTaskGetRunTimeStats()to work.Step 2: Analyze other options
Buffer size being too large does not cause empty output. Passing NULL is invalid. Task priority does not affect stats collection directly.Final Answer:
Run time stats collection is not enabled in FreeRTOSConfig.h -> Option BQuick Check:
Enable run time stats in config [OK]
- Assuming buffer size too large causes empty output
- Passing NULL pointer mistakenly
- Thinking task priority disables stats
vTaskGetRunTimeStats(). Which approach correctly ensures accurate and meaningful stats?Solution
Step 1: Understand requirements for accurate CPU stats
Run time stats must be enabled, buffer must be large enough to hold all task info, and stats should be collected periodically to track changes over time.Step 2: Evaluate each option
Enable run time stats, provide a large buffer, call periodically, and reset counters between calls describes the correct approach including resetting counters to avoid cumulative overflow. CallvTaskGetRunTimeStats()once at startup with a small buffer is insufficient (only once, small buffer). Disable run time stats and manually count task switches disables stats, losing automation. CallvTaskGetRunTimeStats()inside each task to get its own CPU usage is incorrect because stats are global, not per task.Final Answer:
Enable run time stats, provide a large buffer, call periodically, and reset counters between calls -> Option AQuick Check:
Enable + buffer + periodic calls + reset = accurate stats [OK]
- Calling once only at startup
- Disabling run time stats
- Calling inside each task expecting per-task stats
Ready to prove it?
Pass the test and this pattern moves unknown
