Measure Time within a Task with xTaskGetTickCount()

Hi, I am trying to measure the execution time of a function a FreeRTOS task with xTaskGetTickCount(). The code looks like the following example. ~~~ static void prvRxTask( void *pvParameters ) {
for( ;; )
{
    long start = xTaskGetTickCount();
    func_doing_something();
    long stop = xTaskGetTickCount() - start;

    vTaskDelay( pdMS_TO_TICKS( 1000UL ) );

}
} ~~~ My result of stop is always “0” because the xTaskGetTickCount() gets not incremented durring the tasks execution. Why is that so? (I activated the timer in the FreeRTOSConfig.h) If it is relevant, I am using a Zedboard with a Zynq 7000 SoC.

Measure Time within a Task with xTaskGetTickCount()

The tick count gets incremented at every tick interrupt. So the question is what is your tick frequency/period? If you have set it up to 1 ms, you won’t be able to measure something which is faster than that. Or in other words: Keep the Nyquist/Shannon theorem in mind (https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannonsamplingtheorem). What I’m using instead for ARM Cortex-M3/M4/M7 (not sure what you are using) is the Cortex cycle counter (see https://mcuoneclipse.com/2017/01/30/cycle-counting-on-arm-cortex-m-with-dwt/). I hope this helps, Erich

Measure Time within a Task with xTaskGetTickCount()

Hi Eric, it helps a bit. I set the counter to 1000 ticks per second (which is recommended as the maximum). I am using the Cortex-A9 but I want to measure the execution explicit with the tick counter. So even if I replace Funcdoingsomething() with a long while-loop, the counter does not get incremented. My assumption is that the counter gets only incremented before the task gets executed or when he finished. Just not sure if I am right or there is another problem?!

Measure Time within a Task with xTaskGetTickCount()

No – provided you are not in a critical section, the tick count gets incremented on every tick interrupt, no matter which task is running. Are you sure the tick count is incrementing at all? If not, then the call to vTaskDelay() will never return – if vTaskDelay() does return then the tick interrupt is executing [probably] correctly – in which case the next thing to do would be to mearsure the time to check the frequency is as you expect.

Measure Time within a Task with xTaskGetTickCount()

A few additional remarks:
long start = xTaskGetTickCount();
The type long is signed. The result of xTaskGetTickCount() has the type TickType_t, which is always unsigned. In the Zynq port it is 32 bits in portmacro.h: ~~~ typedef uint32t TickTypet; ~~~ Now when you calculate a difference in time, you can use unsigned arithmetic as here below: ~~~ TickTypet xStart, xEnd, xDifference; for( ;; ) { xStart = xTaskGetTickCount(); vTaskDelay( pdMSTO_TICKS( 1000UL ) ); xEnd = xTaskGetTickCount(); xDifference = xEnd – xStart; printf( “Time diff: %lu ticksn”, xDifference ); } ~~~ In the above case, one would expect to see: “Time diff: 1000 ticks”. Can you please verify that? ~~~ long start = xTaskGetTickCount(); funcdoingsomething(); long stop = xTaskGetTickCount() – start; ~~~ The variables here above are never being read, so why would the compiler assign a value to them? When you inspect local variables from within a debugger, you better switch off compiler optimisations (-O0 ). The tick count is incremented from within an interrupt, and that happens independently from what your application is doing. So unless you use an endless critical section ( which disables interrupts ), the tick count should always get updated. When I work with Xilinx/Zynq, I often use a function from their Xilinx library to measure time in micro-seconds: ~~~

define COUNTSPERUSECOND ( XPARCPUCORTEXA9CORECLOCKFREQHZ / ( 2 * 1000000u ) )

uint64_t ullGetHighResolutionTime( void ) { XTime tCur;
XTime_GetTime( &tCur );
tCur /= COUNTS_PER_USECOND;
/* Return the time in micro-seconds. */
return tCur;
} ~~~ My core frequency was 666 MHz. The functions store the time as 64-bits so they won’t overflow quickly.

Measure Time within a Task with xTaskGetTickCount()

Thank you! That answer helped me alot! As you said the counter still gets incremented. My mistake was that the function I wanted to measure was exectued in less than one tick. (Erich mentioned that before) I replaced the function with a very long loop which showed me then a difference in tick time. Btw ty for mentioning the global XTimer – didn’t know that. I was only using the PMU from the ARM processor so far.