returning at *beginning* of task after vTaskD

ivansb wrote on Tuesday, April 19, 2011:

I’ve 2 tasks one that parse input the other that execute actions:

vTaskAction(void *pvParameters ) {
  for(;;) {
    // resume here
    switch (phase) {
      case a_state1:
        // do something
        // do something else
vTaskInput(void *pvParameters ) {
  for(;;) {
    // change phase according to input

I’m using vTaskDelay because it frees CPU cycles inspite of using an internal counter to “delay”.

Now suppose vTaskAction is waiting after it execude vTaskDelay, vTaskInput kicks in and change phase.

I’d like vTaskInput to be able to make vTaskAction to conditionally resume from the beginning of vTaskAction and not from the end of vTaskDelay.

Is there a way I can make a task wait (and not consume cpu cycles) and conditionally restart from where I stopped it OR “reset” the Task and start from the beginning eg. as if the Task was just created and resumed?

davedoors wrote on Tuesday, April 19, 2011:

Instead of calling vTaskDelay( delay_time ), call xQueueReceive( …, …, delay_time ) so delay_time is the block time. Now if you want the task to restart, send a message to the queue telling the task to restart. If it does not receive a message on the queue it will time out and continue as before.

Another way might be to simply delete then restart the task, but that is probably not a good way.

ivansb wrote on Wednesday, April 20, 2011:


If I push something in the queue from vTaskInput, vTaskAction will resume execution.

Is there a way to know how much time passed?

One way could be to use xTaskGetTickCount() but I’m not really sure if it gets the work done as I expect (eg. how overflow should be handled?).


davedoors wrote on Thursday, April 21, 2011:

The tick is an unsigned number so take the tick reading before waiting on the queue, and again after waiting on the queue, then take away the after time from the before time and overflows will not matter (the unsigned number will wrap round). That assumes only one overflow can happen while you are waiting. If there could be more than one overflow then FreeRTOS keeps an overflow count and has some private utilities for working out time differences, but that would need digging around in the code internals.