Hallo, I wonder about the performace decrease and increment of footprint for: ~~~ configGENERATERUNTIMESTATS configUSETRACEFACILITY configUSESTATSFORMATTINGFUNCTIONS ~~~ 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

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. configGENERATERUNTIME_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). configUSETRACEFACILITY mainly just brings in additional functions, which will normally only add code size if you use the functions. Other impact is minor. Again configUSESTATSFORMATTING_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.

configGENERATERUNTIMESTATS set to 1 make me to declare also ~~~ portCONFIGURETIMERFORRUNTIMESTATS() portGETRUNTIMECOUNTERVALUE() ~~~ 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

Have you looked at using FreeRTOS+Trace? http://www.freertos.org/trace

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

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( configUSETRACEFACILITY == 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; + } } #else ~~~ ( 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. Regards.