xTaskNotifyWait and notification nesting

Dear All, I use FreeRTOS 9.0.0 and can see that I miss notifications when they arrive several times before calling xTaskNotifyWait. In a given task if two interruptions TX and RX occur where each of which sets its own notification then the subsequent xTaskNotifyWait call will tell about the requested notification, however, internally it will reset the notification status with the line: pxCurrentTCB->ucNotifyState = taskNOTWAITINGNOTIFICATION; although the pxCurrentTCB->ulNotifiedValue correctly holds both events but it is not checked anymore. So one is able to track the TX notification but not the RX if both occur before the first xTaskNotifyWait call. Is this done so by design or is a bug? Not being able to track nested notifications greatly limits its usage. Thanks a lot for any comment in advance.

xTaskNotifyWait and notification nesting

You simply should process the complete notification value/bit set when the task gets notified ie. in your case check for Tx and Rx events. The notification mechanism is lean and fast by design. So don’t expect too much comfort you otherwise have to pay for 😉 Good luck, HS2

xTaskNotifyWait and notification nesting

Thanks for the feedback. IMHO implementions of the nesting i.e. having ucNotifyState to be treated in a bitwise manner similar to ulNotifyValue could be enough for the nesting to work without compromising the speed.

xTaskNotifyWait and notification nesting

There are lots of ways of sending an event from an interrupt to a task. Direct to task notifications are the fastest and leanest and are the best choice in the majority of scenarios – but not all scenario. You have to choose the best option (event group, queue, semaphore, etc.) for your particular scenario. However I don’t see why using a notification would not work for you. You don’t say how you are using the notification though. Are you using the ‘set bit’ action? If so use one bit for the Rx interrupt and one bit for the Tx interrupt. Then when you receive a notification, check both bits to know what to process – and process both interrupts if both bits are set. Further, setting a bit doesn’t tell you how many interrupts have occurred, so when you do process an Rx interrupt, don’t assume only one is pending – maybe there are two or more waiting to be processed. If you don’t want to do that in your application code then use a different synchronisation mechanism, like a queue.

xTaskNotifyWait and notification nesting

Thank you for the detailed explanation. I agree with all your statements. Actually, I do not have a problem with notifications and everything works (if I keep processing the TX and RX ASAP). Processing of several bits like TX and RX at one place may not be that nice in terms of code organization. I thought that it could be relatively easy to have for a task tracking several notifications (each of which could have occured more than once), just by making ucNotifyState bitwise processable like it is for ulNotifyValue. At least I do not see why ulNotifyValue can be based on bit processing and the ucNotifyState not. But I might be wrong. In any event I find FreeRTOS very comfortable.