What is the effect if a task is suspended with vTaskSuspend() that has vTaskDelayUntil() in the task? When the task is resumed – will it pick up with the tick count as is before it was suspended or does the tick count resume after vTaskResume() is called? For example – let’s say that task1() has an xFrequency 250 – it runs at xTickCount = 250 Let’s say it is suspended at xTickCount = 260. Let’s say it is resumed at xTickCount = 270. Does the task run again at xTickCount = 500 or xTickCount = 510 (520)?

At 500. The vTaskDelayUntil() maintains an absolute time at which the task is to execute again.  There is only a single tick count maintained by the kernel, which is continuously measuring the passing of time.  vTaskDelayUntil() will suspend the task until the tick count has equalled the wake time (passed into vTaskDelayUntil()).  If the wake time contains a time that has already passed then the task will not suspend at all. Regards.

The task will block until the time you tell it to wake.  You have control over this using the parameter passed to vTaskDelayUntil.

So, calling vTaskSuspend() in this case does nothing?

Calling vTaskSuspend() suspends the task, so it does something. I think this requires clarification.  Here is an example. Task A has the following structure, { portTickType xNextWakeTime; ____xNextWakeTime = xTaskGetTickCount(); ____for(;;) ____{ ________vTaskDelayUntil( &xNextWakeTime, 200 ); ________vTaskSuspend( 0 ); ____} } The task calling vTaskDelayUntil() suspends itself. When vTaskSuspend() is called the task suspends, and remains suspended until resumed by another task. The value of xNextWakeTime does not change while the task is suspended, and the behavior is predictable.  When the task is resumed it calls vTaskDelayUntil() again and will delay until the time at which you have requested to be unblocked which is 200 ticks after the previous time you unblocked.  The fact you have been suspended in between has no bearing on this UNLESS you have been suspended for more than 200 ticks.  If you have been suspended for more than 200 ticks then when you call xTaskDelayUntil() the time ( xNextWakeTime + 200 ) will already have passed.  You are asking to be woken at a time that has already elapsed, so you don’t block at all.

OK – thanks.  So – if the time for vTaskDelayUntil() has passed while the task has been suspended – it will execute immediately when vTaskResume() is called. This makes sense – and thanks for clarifying.  I’m glad it works this way. John W.

The following does not create the scenareo that I think John asked about. { portTickType xNextWakeTime; ____xNextWakeTime = xTaskGetTickCount(); ____for(;;) ____{ ________vTaskDelayUntil( &xNextWakeTime, 200 ); ________vTaskSuspend( 0 ); ____} } This would never suspend while itself is delaying. Keep in mind how vTaskDelayUntil differs from vTaskDelay. The question is if (1) task1 calls vTaskDelayUntil(200) (2) at tick 100, task2 suspends task1 (3) at tick 300, task2 resumes task1 Here are some events that might happen depending on how the scheduler is implemented: - Does task1 resume at 200 because it was scheduled, even though it was suspended? - Does task1 resume immediately when task2 resumes it, detecting that it has passed 200? (I guess should happen) - Does task1 remain in a delay state for days until the next time the count reaches 200?

Not sure if this was the question – but its a bit ambiguous maybe. When task1 calls vTaskDelayUntil it is placed in a list of delayed tasks. When task2 suspends task1, task1 is removed from the delayed list and placed in the suspended list.  Tasks in the suspended list are just left to fester and are not touched. When task2 resumes task1, task1 is removed from the suspended list and placed in the ready list.  This will happen no matter what the elapsed time (more, equal to or less than 200).  The resume supersedes the delay until. Regards.