Hi all,
I configured timer to set event with fixed period (100ms). The event is used to execute task with fixed period, using xEventGroupWaitBits API.
Within the task I need to wait for response (around 3ms to 8ms) its not a fixed time and I want to put the task in wait state for this 3 to 8ms.
can someone guide me how to do it?
What is the substitute method or API in FreeRTOS equivalent to " WaitEvent(Event_Flag) " in Autosar.
Regards,
Kishor
Your question is not very clear - how is fixed period and response related? Would you please elaborate?
If you want to block for an event, you can use task notifications: FreeRTOS task notifications, fast Real Time Operating System (RTOS) event mechanism
A task is running with 100ms period which is activated using timer + event mechanism.
Within a task after sending request for data I want to block the task till the response which will be around 3 to 8ms.
Its like event within event. I hope I am able to explain the scenario.
Regards,
Kishor
How are you notified of the response? Assuming that it is an interrupt, can you
do somthing like the follwing:
void TaskCode( void * pvParams )
{
( void ) pvParams;
for( ;; )
{
/* Start the request - the response will arrive in next 3-8 ms. */
MakeRequest();
/* Wait for the response. */
ulNotificationValue = ulTaskNotifyTake( pdTRUE,
xMaxBlockTime );
if( ulNotificationValue == 1 )
{
/* The response was received. */
}
else
{
/* The call to ulTaskNotifyTake() timed out. */
}
/* Sleep for 100 ms. */
vTaskDelay( pdMS_TO_TICKS( 100 ) );
}
}
/*-----------------------------------------------------------*/
/* The response received interrupt. */
void vResponseReceivedISR( void )
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
/* Notify the task that the transmission is complete. */
vTaskNotifyGiveFromISR( xTaskToNotify,
&xHigherPriorityTaskWoken );
/* If xHigherPriorityTaskWoken is now set to pdTRUE then a
context switch should be performed to ensure the interrupt
returns directly to the highest priority task. The macro used
for this purpose is dependent on the port in use and may be
called portEND_SWITCHING_ISR(). */
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
/*-----------------------------------------------------------*/
I am using the task notification here as binary semaphore as described here - FreeRTOS task notifications, fast Real Time Operating System (RTOS) event mechanism
Thanks.
Thank you for the reply,
Can you please tell me what will be the task state after calling below functions?
/* Wait for the response. */
ulNotificationValue = ulTaskNotifyTake( pdTRUE,
xMaxBlockTime );
Will it put the task in wait state or ready state?
/* Sleep for 100 ms. */
vTaskDelay( pdMS_TO_TICKS( 100 ) );
Will it put the task in wait state or ready state?
I want MCU resources to be used during this period during the delay functions task must be pushed to wait state since task is of extended type.
Regards,
Kishor
Have you viewed the documentation and examples for these API functions? I think you will find the answers there.
The document mentions “blocked state” it is equivalent to suspend, ready or wait state. The terminology is quite confusing, please make it clear.
Regards,
Kishor
Blocked means waiting for something. I think it’s pretty common terminology.
thank you very much for confirmation.
In addition to the online documentation I would recommend taking a look at the book - it is out of date but the fundamentals haven’t changed.
I want to clarify few more things,
Que 1:
Wait or block state means MCU is free to execute other task which are in ready state. am I correct?
In this scenario is it required that ready state task should have higher priority than blocked task.
Que 2:
If task calls a function which again calls another function in which “vTaskDelay(xms)” is called how does it keeps the track of particular task and puts it in wait state?
Regards,
Kishor
Wait or block state means MCU is free to execute other task which are in ready state. am I correct?
Yes, you are right.
In this scenario is it required that ready state task should have higher priority than blocked task.
No, a blocked task cannot run. At any point in time, the highest priority ready task runs.
If task calls a function which again calls another function in which “vTaskDelay(xms)” is called how does it keeps the track of particular task and puts it in wait state?
A task can be thought of an independent unit of execution. For example, the following diagram shows 2 tasks T1 and T2 which calls different functions:
Task T1 Task T2
f1() g1()
| |
| |
f2() g2()
| |
| |
f3() g3()
Whichever tasks calls vTaskDelay functions, it put to the blocked state.
I’d strongly recommend to read the book Richard linked - chapter 3 explains task management in detail.
Thanks.
Can I get this book online?
This is what my exact question? does it block the particular function example g2 or g3?
How does it keep track of the Task? if it just blocks the sub-function in that case task is running and the delay acts as busy-wait, which will loose MCU resource.
Regards,
Kishor
Blocking is related to tasks / threads, not functions. Functions called in a task belong to this task i.e. to this ‘thread of execution’.
I’d recommend to read the docs and maybe other explanations in the web to get more familiar with basic multi-tasking concepts.
Thank you for reply,
I got your point, since the vTaskDelay(xms) function can be called from sub-section not directly from task, how does it keep track of the parent task and puts that particular task in block state.
Regards,
Kishor
The system knows which task is the currently running task, and vTaskDelay will delay that current task.
To clarify … the operating system ALWAYS knows which task is running, so when you call xTaskDelay() it is from within the currently running task and therefore the operating system will put the currently running task into the blocked state.
You do not need to keep track yourself of which task is running.
Once the currnetly running task enters the blocked state, the task with highest priority which is in the ready state will transition to the running state.
Thank you very much for the clarification