Use xTaskNotifyWait to wait on single bit

daveskok wrote on Tuesday, July 26, 2016:

I am using xTaskNotify/xTaskNotifyFromISR/xTaskNotifyWait in an application using v8.2.3 FreeRTOS. There is a point in a task that I want to wait on a single bit to be set with timeout. At that point it is possible that other bits could be set but I don’t care about them right then and there but I can’t clear them because they will need to be acted on at a later time and place. The problem I have is that if a bit that I don’t care about is set at that point in time will cause xTaskNotifyWait to return.

I am trying to be “cheap” by using the xTaskNotify/xTaskNotifyWait for notification at multiple points in code where I expect a specific bit to change. I could just as well use a separate semaphore at the aformentioned point in code. An alternative might be to save set bits I don’t care about then and there and clear them in notification. Problem with that is extra overhead keeping track of time lapsed.

I read docs and it does not appear that API supports waiting on specific bits but I thought I’d ask anyway.

Thanks in advance.

rtel wrote on Tuesday, July 26, 2016:

If you use a task notification as a light weight event group you would
have to do some work manually - for example not clear any bits
automatically, and instead manually clear just one bit manually after
you have unblocked (if that is possible, not checked the API).

Alternatively you can use an event group, in which case everything you
want to do is possible without any manual work (i.e. no additional API
calls) - however using an event group from an interrupt is much slower
than using a task notification.

hengblom wrote on Tuesday, July 26, 2016:


If I understand you correctly, I made a patch for that very sitaution. It is not the most beautiful code, I’d prefer to never notify a task the waits for specified bit, but instead in this patch it is notified, but “pushes the event back” to the pxCurrentTCB->ulNotifiedValue.

Attached is the patch, based on FreeRTOS 8.2.0

br Håkan

daveskok wrote on Wednesday, July 27, 2016:

It is indeed the solution I was looking for and had considered creating the API as you did. I am hesitant to add to API as it may not work in future FreeRTOS versions.


hengblom wrote on Wednesday, July 27, 2016:

True, it is always a risk to add “private” code to “community” code.

I’ve been thinking about trying to make it part of the official FreeRTOS, but I’m not familiar with the procedure to contribute to FreeRTOS, so I’m hesitating. (And I don’t know if they want it either)

daveskok wrote on Wednesday, July 27, 2016:

I am probably not going to use the modification but hope that the API is added by maintainers. I would like to point out a possible oversight at the point in code where:

pxCurrentTCB->eNotifyState = eNotWaitingNotification;

If any bits other than the one you’re waiting on are set at that point in code the value of eNotifyState should be set to eNotified otherwise set to eNotWaitingNotification. This as opposed to always setting to eNotifyState to eNotWaitingNotification. This way at some other place in code that is interested in the other set bits the notification will still be pending.

Just saying.

hengblom wrote on Thursday, July 28, 2016:

Yes, you’re right. I’ve only used “my own” ulTaskNotifyWaitSelective() function, and then it does not matter since it looks only on pxCurrentTCB->ulNotifiedValue and not on pxCurrentTCB->eNotifyState, and then it works anyway.
But if xTaskNotifyWait() had been called in some cases, it would not have worked as expected.