eadlwise wrote on Wednesday, May 09, 2018:
Hi,
I have used event bits in order to enjoy Inter-Task Comm. (ITC) between a task which recieves messages in the form of bits from different tasks and ISRs.
The event bits are fine from usage perspective, but are rather slow from performance perspective.
In order to have better performance, i have tried to migrate to direct task notifications as light-weight event bits, which are better performance wise.
The problem is, that although the the freeRTOS kernel states that notifications can be used as lightweight event bits, i find this to be inaccurate.
From my POV, Event bits can be described as a shared memory that different tasks and ISRs may use for ITC. The exact method for setting, clearing, getting or waiting on the bits is left for the user to decide and design. The freeRTOS APIs allows the manipulation of these bits in a safe manner.
On the other hand, the task notification value is a dedicated 32 bitmap which resides inside the task’s control block.
As opposed to event bits (EBs):
- There is no option to extend this bit number of notifications - EBs may be allocated as much as we want (up to memory limitations etc.).
- EBs may be used to signal several tasks. Notifications are mainly used to signal only the task which they belong to.
- There are several more minor functionality limitation, such as waking on some bit configuration etc.
But as far as i’m concerened, apart from the mentioned constraints (which are acceptable by me), i expect the TNs to have the same (or nearly-approximate) functionality as the event groups.
There seems to be a great difference between the capabilities and methodology of the EBs and TNs.
In particular:
- Event group bit set - in the notification value, setting bits option is always accompanied by
notifying the task, leading to unwanted task wake up. - Event group bit clear - In TN, there is no API which can clear, or test and clear some wanted
bits. The only way that these bits may be cleared is via the “xTaskNotifyWait” which doesn’t
seem to be the correct way of just clearing some bits. - Event group bit get - The only apparant way to retrieve the notication bitmap is using the
“xTaskNotifyAndQuery” with “eNoAction” specified as the wanted action. Alas, the query
itself results with a new notification delivered to the task! A very unfortunate side effect for a
mere query mechnism.
Additionaly, There is no way knowing if a notification is pending other then running into the “xTaskNotifyWait”! This seems to be a rather “heavy-weight” option for getting information on “light-weight event bits”.
This is quite unfortunate, as all of those functionalities seem to be rather simple to implement as part of the formal APIs.
So, summing it up: Although the TN are described as a light-weight event bits, the real (formal) functionlity is pretty far from it.
Although performance wiseTNs are better than event bits\groups, the usage of it limits the user for a strict usage pattern and by so limit the possibilities of the user for a more versatile SW design.
The bitter laugh here, that with some additional very light weight APIs (which are definitly easy to implement) the situation would’ve be better by far from the current one.
I will be happy to hear your opinion regarding this matter, and also for you to point out my misunderstanding (if any).
Thanks!
Hagay.