performace and increase of flash footprint of some configs

mastupristi wrote on Thursday, February 23, 2017:

I wonder about the performace decrease and increment of footprint for:


I run FreeRTOS on a Cortex M4 core, and I am afraid about context switch time, task wakeup latency from ISR, etc.

Those configs was added for debugging purposes only?

best regards

rtel wrote on Thursday, February 23, 2017:

You can look in the source code to see where these constants are used,
and their impact. A quick grep on a handful of files is all you need to
do. None of the options are required. If you turn the options on then
there is an impact on overhead - functionality takes code and code takes
time to execute.

configGENERATE_RUN_TIME_STATS will add an additional load and store in
the context switch as the counter is read and stored (possible also an
add too, can’t remember).

configUSE_TRACE_FACILITY mainly just brings in additional functions,
which will normally only add code size if you use the functions. Other
impact is minor.

Again configUSE_STATS_FORMATTING_FUNCTIONS just brings in other
functions, and has dependencies on library functions. Dependencies on
library functions can have a big impact on your code size, but that is a
compiler issue not a FreeRTOS issue. For example, calling sprintf()
with a GCC compiler that is not optimised for MCU use can bring in loads
of floating point libraries which can more than double the size of your
application - whereas calling the same function with a tailored version
of sprintf() or a specialise embedded compiler might just add a few
bytes to your code size.

mastupristi wrote on Sunday, February 26, 2017:

configGENERATE_RUN_TIME_STATS set to 1 make me to declare also


I can use a Timer but my hw (Kinetis K64) has 16bit timers that runs @60MHz. I make it run 10 time faster than Tick timer, so I have the interrupt triggering @10KHz.

I wrote a sample program with which I could see that the statistics are collected starting from boot.
Suppose that I have a high priority task that normally is idle (near 0% CPU usage). After certain condition it takes as much CPU as possible (near 100% CPU usage) for ten or more seconds, and then it switch back to idle.
The stats collected starting from boot will never say that the task is consuming 100% of CPU when it runs and 0% when it is idle. Tay always give a mean of CPU usage.
I wonder if it is possible, and how, make the stats behave like moving average. In other words how is possible to have an almost instantaneous estimates of CPU usage?

bast regards

rtel wrote on Sunday, February 26, 2017:

Have you looked at using FreeRTOS+Trace?

mastupristi wrote on Sunday, February 26, 2017:

this not help me.
I want to print periodically those infos on the console UART.

best regards

heinbali01 wrote on Sunday, February 26, 2017:

I’m guessing: if you were able to clear the counters of the task’ CPU-times, you can make what you want?

As a temporary solution, you could do the following, based on version v9.0.0 :

tasks.c, line 3409:

 #if( configUSE_TRACE_FACILITY == 1 )
+    /* When the global variable 'xTaskClearCounters' is
+    non-zero, the field 'ulRunTimeCounter' will be zero'd. */
+    BaseType_t xTaskClearCounters;

     void vTaskGetInfo( TaskHandle_t xTask, TaskStatus_t *pxTaskStatus, BaseType_t xGetFreeStackSpace, eTaskState eState )

tasks.c, line 3456 + 3:

         #if ( configGENERATE_RUN_TIME_STATS == 1 )
             pxTaskStatus->ulRunTimeCounter = pxTCB->ulRunTimeCounter;
+            if( xTaskClearCounters != pdFALSE )
+            {
+                pxTCB->ulRunTimeCounter = 0;
+            }

( the lines starting with a + should be inserted into your copy of tasks.c )

Now you collect all CPU times, e.g. every second by calling uxTaskGetSystemState().

    extern BaseType_t xTaskClearCounters;

    if( time to make logging )
        xTaskClearCounters = pdTRUE;
        uxTaskGetSystemState( xTaskStatusArray, ARRAY_SIZE( xTaskStatusArray ), &ulTotalRunTime );

I would like to submit a change request, asking for the possibility to clear all counters (the field ulRunTimeCounter), and also to add a new counter called ulSwitchCounter. I would like to know how many times each task has become active. This can be helpful when tuning the power consumption of an application.