Quality RTOS & Embedded Software

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




Loading

returning at *beginning* of task after vTaskD

Posted by IvanSB on 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
vTaskDelay(N);
// 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?




RE: returning at *beginning* of task after vTaskD

Posted by Dave on 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.

RE: returning at *beginning* of task after vTaskD

Posted by IvanSB on April 20, 2011
Perfect.

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?).



thanks

RE: returning at *beginning* of task after vTaskD

Posted by Dave on 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.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

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