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:
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.
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
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.
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.
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.
