Please help me I’m not much familiar with rtos I have a doubt in vTaskDelayUntil(), it used to implement a task that executes periodically and with a fixed frequency. My doubt is if i want to execute five different tasks in every 5 seconds using vTaskDelayUntil() as shown below
I calld this in five different tasks and my configTICK_RATE_HZ is 100. My single task will take 3 seconds to complete its process.Then how will it execute the code??
Thank you for reply. So if i want to execute five different tasks in every 5 seconds i have to set same priority for all my tasks right?. if so will it execute in every 5 seconds exactly?
No. Using VTaskDelayUntil in the task loop will make that task run as close to that rate as possible. It will only be late if:
Some higher or equal priority task is running at the point, in which case the task will be delayed until the higher priority task blocks, or the same priority task blocks or continues for a tick.
It takes longer to finish than the repeat period, at which point the vTaskDelay Until doesn’t block, but just updates the next execution time an returns.
You mentioned one task taking a long period to execute, If that is compute bound time, then you probably don’t want that task higher priority than the others, as it would affect their timing. Long executing tasks (if CPU bound) tend to be lower in priority to avoid them impacting more important quick operations.
Hello sir, How much is the maximum available delay in vTaskDelayUntil() ? The xTimeIncrement is Short, so i can set only up to 65536( 6.5 seconds) right? If i want a delay more than this what will i do? i set unsigned long xTimeIncrement instead of portTickType xTimeIncrement is this a proper way?. i want to set delay up to 1hr in some tasks.
I have no idea what xTimeIncrement is, so the answer to your question is probably “no”.
Block times are specified in ticks, so the maximum time you can block for depends on your tick frequency (configTICK_RATE_HZ in FreeRTOSConfig.h) and the type used for portTickType. If configUSE_16_BIT_TICKS is 1 then the maximum block time is 0xffff ticks. If configUSE_16_BIT_TICKS is 0 then the maximum block time is 0xffffffff ticks.
If you want to convert milliseconds into ticks then divide it by portTICK_RATE_MS. For example, of you want to delay for 1000 milliseconds then call vTaskDelay( 1000 / portTICK_RATE_MS );
When you are blocking on an object such as a queue, semaphore or mutex then you can block indefinitely (without a timeout) if INCLUDE_vTaskSuspend is set to 1 in FreeRTOSConfig.h and you set portMAX_DELAY as the block time.
At a 1 ms timer tick, and 16 bit ticks, you get 65.5 seconds as the maximum delay you can request. Timer ticks faster than 1 ms are really impractical, and some of the coding techniques in the examples don’t work (as MS_PER_TICK is 0). In most application you can actually use a slower tick rate. A 10ms tick would allow a delay of 655 seconds, nearly 11 minutes. If you want real long delays, you need to turn off 16 bits as mentioned, then you get VERY long delays (Over a month with 1 ms ticks).
Forgive me if i’am doing wrong.i wrote program for delay as shown below, here i can set any delay 20mins, 50mins, 1 or 2 hrs or more. But i didnt change my code as you said.
UploadTime * 1000 / portTICK_RATE_MS sys UploadTime is in SECONDS, not minutes.
At 100Hz, a 16 bit tick will allow a maximum delay of 655 seconds, i.e. about 11 minutes.
Note that if you have a 16 bit processor, then your calculation will overflow long before the timer call, and this will actually limit your max delay to about 65 seconds.
Yes, 16 bit processors can set configUSE_16_BIT_TICKS to 0, and get a 32 bit tick size. There will be slightly extra work done to process ticks as tick arithmetic will use 32 bit longs, which will require twice the instructions to do the math (in most cases), but this is not that big of a hit, especially if you need the long time measurement/delays.
if you really want to wake up exactly every sec seconds.
NOTE: if you use sleepUntil then you must call it before the base timer overflows - 65 secs with 1000Hz or 655 secs with 100Hz which I assume is not an issue.