That is a solution. However, notification counter is there already. I was hopping that native OS counter could be used. It looks like it is not easily done due to the way it behaves.
Still would like to have the answer on feasibility of using eTaskGetState().
Looks like it is usable - see the source
FreeRTOS-Kernel/tasks.c at 4162ca49d6aa1bdef940e09b71c28b51779db523 Ā· FreeRTOS/FreeRTOS-Kernel Ā· GitHub.
Maybe due to list lookups not generally recommended in ISRs ? Donāt know.
but you keep using the term ātask instanceā which implies that tasks terminate before being reactivatedā¦
anyways, you may want to look into queues instead of task notifications in your use case. If a task needs more (CPU bound) time to process an event than the next event takes to request processing, there is nothing you can really do about it. A queue (possibly with the time stamp of the event occurrences as the queue payload) gives you a at least a chance to process the ālostā event posthumously.
As I said. the problem with eTaskGetState is it has false negatives, as the task might be blocked for I/O while processing, and not yet ādoneā with its processing. It also uses a plain (not for ISR) critical section, so canāt be used in an ISR.
As to the Notification counter, your problem is that reading it as a counter always decrements it at the reception, and thus you DONāT have anything to mark when the task actually finishes to detect overrun.
If instead you use setting/clearing a bit, and if you only allow 1 accumulation of the counter, why couldnāt you, you could xTaskNotificationWait to wait for the bit to be set, and then NOT clear it at that point, and clear it when done.
To all who replied to this post.
Thank you for your suggestions and support. I should have enough community insight into what is appropriate solution to the problem of multiple activations with minimal overhead.
Regards,
Eugene