FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to 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.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2017 Threads] xTaskNotifyWait and notification nestingPosted by davhak on February 25, 2017 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 nestingPosted by hs2sf on February 25, 2017 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 nestingPosted by davhak on February 25, 2017 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 nestingPosted by rtel on February 25, 2017 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 nestingPosted by davhak on February 25, 2017 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|