Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


vTaskDelayUntil modified behaviour

Posted by lctromnml on June 20, 2016

I have a task that periodically that does some calculations and finally sends data from the calculation onto CAN. The task uses vTaskDelayUntil to be called with a fixed frequency. The problem is, that the task has different execution times: Every for example 10 times the calculation takes significantly more time (still not as long as the fixed frequency the task is called). The task is therefore correctly executed with a fixed frequency but the sending onto CAN in the end of an execution cycle is always delayed, when the calculcation takes longer.

My goal is that the sending is periodically.

I could resolve this problem easily when placing the vTaskDelay between the calculation and the sending onto CAN. However, this would mean that I send the data much later than it is available.

So basically I would have to separate the measurement of the execution time and the call of the vTaskDelayUntil.

Is there a simple possibility with FreeRTOS-API-Calls to solve this problem or do I have to measure the execution time myself and call vTaskDelay myself?

vTaskDelayUntil modified behaviour

Posted by rtel on June 20, 2016

I'm not sure I understand. If you are using vTaskDelayUntil() as per the API documentation then the task will execute with an exact period (assuming it is the highest priority task that is able to run when the vTaskDelayUntil() function returns). If the time between vTaskDelayUntil() returning and the CAN message actually being output onto the bus varies because the calculation performed after vTaskDelayUntil() returned varies then that would seem to be a characteristic of your system - rather than an RTOS specific thing.

I would think you need to decide what is most important to the stable running of your system - the time the calculation starts (in which case the way you have the code now will give the best result) - or the time the result of the calculation goes onto the bus (in which case you can wake from vTaskDelayUntil() earlier, perform the calculation, then wait whatever time remains before the data is output onto the bus).

vTaskDelayUntil modified behaviour

Posted by lctromnml on June 20, 2016

Thanks for the fast reply. And yes, I am using vTaskDelayUntil() as per the API documentation and the task executes (means: starts to calculate) with an exact period, I verified this also with Tracealyzer.

Important to the stable running of my system would be, that the CAN message is sent exactly periodically, but immediately after the calculation is done, no matter how long the calculation takes (which is always shorter than the frequency the task is called).

I guess there is no clean way to do this with vTaskDelayUntil() or other RTOS API functions (like manipulating the laskWakeTime variable that is passed by reference to vTaskDelayUntil())?

I tried now to measure the time the calculations take myself and used vTaskDelay() with varying ticks to wait: Whenever a "short" calculation will be followed by a "long" calculation, the ticks are reduced by the time, the "long" calculation takes so that the task executes with a fixed frequency regarding the point the CAN message is sent. By now it seems to work.

vTaskDelayUntil modified behaviour

Posted by richard_damon on June 21, 2016

If you know (or can estimate) how long the NEXT calculation will occur, then you can modify the parameter in the call to vTaskDelayUntil by subrtracting the estimated time of the next calculation and adding the extimated time of the previous calculation. Then your sends will be uniform to the precision of you estimate of the calculation.

This would be basically the same as keeping a moving time stamp of when you wan to send your next message, subtract the estimated time of computation, and subtract the current timestamp, and then increment the moving time stamp by one period.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner