xTicksToWait in xTaskNotify(…) Function

  • 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(…) Function

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(…) Function

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(…) Function

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(…) Function

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(…) Function

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.