Greetings, 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.

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.

Hi,

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

Thanks, 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.

gualterio

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)

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.

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.