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.