Notifying other tasks from a Timer callback

amilaperera wrote on Wednesday, February 07, 2018:

What would be the most accepted way to notifying other tasks from a timer callback.

I have framework where each task has its own Queue and waits for the queue. When a timer expires I would ideally want to send a message to the queue allowing the task to process the timer expiration. But still there’s a chance that the queue is filled which in turn might keep the timer callback blocked which is not good. Of course, I can pass 0 as the block time, but this in turn would return without placing the item(when the queue is full), in which case I will miss the timer notification entirely.

Are EventGroups better way to handle this than Queues ?

Are the events in FreeRTOS queued ? If another event arrives while the current event being processed, will the latest event be missed ?

I know that Q1 & Q2 are not related, the second question just came to mind while thinking about event groups for this particular case.

Thank you for the help in advance.


rtel wrote on Wednesday, February 07, 2018:

Are the events in FreeRTOS queued ? If another event arrives while the
current event being processed, will the latest event be missed ?

I’m assuming here you are referring to an event bit being set as the event.

Event bits are binary, they are either set or not, so if a bit is
already set when another event occurs it cannot be set again and the
information that two events occurred is lost. You could use a counting
semaphore to avoid that - counting semaphores keep a count of events
that occur so increment each time the semaphore is given and decrement
each time the same semaphore is taken.

If there is only one reader and one writer then you could consider using
a message buffer instead of a queue - that would be more efficient, but
doesn’t get around your problem of what to do if the queue is full.

One option might be to have the priority of the timer task below the
priority of the tasks that drain the queues - that way the timer task
would always find the queues empty. An advantage of that is you could
use shorter queues and save RAM - however maybe that is not feasible as
I don’t know the requirements of your system.

amilaperera wrote on Wednesday, February 07, 2018:

Hi Richard,

Thank you for the clarification.
I understand that events are not queued and it is just a bit being set/cleared, and consecutive events won’t get registered.

For notifying other tasks from the timercallback, the best option I would think is the last mentioned one. I really had it in my mind, but it is a commitment that all the other tasks should make as not to prioritize thier tasks above the timer task - my system will eventually have a dozen of tasks.
But in my case, I assume this should be fine, since I can make a single higer priority task(core system task that communicates with all the other tasks in the system) handle all the timer callbacks which in turn can notify the other tasks simpy by writing to their respective queues.

Thank you once again for the valuable feedback.


richard_damon wrote on Thursday, February 08, 2018:

One way to handle you issue that comes to mind is that you could create a dedicated task with a counting semaphore that the timer signals, then that task signals all the others. That way the timer task can’t find a full queue (you can allow the counting semaphore to count to a fairly large value, so if you fall that far behind something is really wrong),