|
NOTE:This is a read only archive of threads posted to the FreeRTOS support forum. Use these archive pages to search previous posts. New forum support threads can be started at the FreeRTOS forums.
FreeRTOS Support Archive
The FreeRTOS support forum can be used for active support both from Amazon Web Services and the community. In return for using our software for free, we request you play fair and do your bit to help others! Sign up for an account and receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum. Use these archive pages to search previous posts. New forum support threads can be started at the FreeRTOS forums.
[FreeRTOS Home]
[Live FreeRTOS Forum]
[FAQ]
[Archive Top]
[August 2019 Threads]
xTicksToWait in xTaskNotify(…) FunctionPosted by panu28 on August 10, 2019
- xQueueSend(xQueue,pvItemToQueue,xTicksToWait)
- xTaskNotify(xTaskNotify,ulValue,eAction)
Why is there no** “xTicksToWait”** for xTaskNotify(…) **Function while there is one for **xQueueSend(…)
Why is Symmetry missed ?
P.S. : Also note the Assymetry in Naming Convention:
{xQueueSend, xQueueRecieve}
** vs** {xTaskNotify, xTaskNotifyWait} ** instead of** {xTaskNotifySend, xTaskNotifyRecieve}
xTicksToWait in xTaskNotify(…) FunctionPosted by heinbali01 on August 10, 2019 I am sure that a better or more detailed answer will follow, but here is mine:
xTaskNotify() may need to wait for space in a queue.
When notifying a task, there is no queue, the task will be notified immediately.
xTicksToWait in xTaskNotify(…) FunctionPosted by heinbali01 on August 10, 2019 sorry, typo: xQueueSend needs a time-out parameter because it may have to wait for space in the queue. xTaskNotify() can do it’s job immediately.
xTicksToWait in xTaskNotify(…) FunctionPosted by richard_damon on August 10, 2019 As Hein says, there is nothing for xTaskNotify to need to wait for. xTaskNotify is more like xSemaphoreGive than xQueueSend, in that a notification doesn’t need to wait for ‘space’ for the notification. The eAction parameter describes what is done with the value word, and note that none of the options require waiting, there is an option that will report a failure if the current notification value is non-zero.
Note that since there is no option to wait for the task to take the old value first, the direct to task notifications isn’t a full replacement for a queue, but then even if you try to use it as one, it can’t really handle reliably sending the value 0.
xTicksToWait in xTaskNotify(…) FunctionPosted by panu28 on August 10, 2019 Hi, Thanks for reply …
When notifying a task, there is no queue, the task will be notified immediately. xTaskNotify() can do it’s job immediately.
But Consider the scenario Recieveing TASK- has still a notification pending which it hasnt processed….. and another TASK- wants to send notification to TASK-
e.g: (Below Lines of Code could have been Avoided? if functionality was inbuilt)
~~~
RETRYNOTIFICATION:
if (xTaskNotify(hThreadleds, stv, eSetValueWithoutOverwrite) == pdTRUE)return true;
if (timeoutms) { vTaskDelay(pdMSTOTICKS(1)); timeoutms–; goto RETRY_NOTIFICATION; }
~~~
P.S. : I Think xTaskNotify() has “queue” of size – 1
xTicksToWait in xTaskNotify(…) FunctionPosted by richard_damon on August 10, 2019 As I mentioned, Notify isn’t built on the model of a Queue, but more on the model of a semaphore. It seems not designed to be used as a Queue.
I suspect the reasoning is that if you really want a Queue like system, then likely you may want a Queue length greater than 1, but by the nature of how notifications are built, they are inherently limited to just a single mailbox word for the notification. If you want q Queue, use a Queue (or a Stream/Message Buffer)
The other factor is that the big advantage of the Direct to Task system is that it is much more efficient than using a Semaphore (or a Queue), because there is no need to have lists of tasks waiting for the notification. To allow tasks to queue up and wait for a notification to be taken removes this advantage. As currently defined, the task being notified doesn’t need to do anything much to receive the notification, maybe just clear the notification word. If there was a posibility of a task waiting on that, then after every notify take FreeRTOS would need to check about waking up somebody, at which point the Direct to Task Notification has no real advantage over using a Semaphore or a Queue. The restrictions on usage are what gives it the advantages that make it useful.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|