FreeRTOS timers

sarahaka wrote on Wednesday, November 21, 2018:


I have a question regarding FreeRTOS software timers.

  1. I know that all software timer callback functions execute in the context of the same RTOS daemon (or ‘timer service’) task.
  2. I know that this “timer task” has a priority and that it enters the blocked and ready state based on whether it recieved a command in the queue or not.
  3. I know that the the time at which the software timer being started will expire is calculated from the time the ‘start a timer’ command was sent to the timer command queue—and not from the time the daemon task received the ‘start a timer’ command from the timer command queue.
  4. HOWEVER when the timer expires, the “timer task” transits to the ready state to run the callback function. What if its in the ready state but higher priority tasks are currently running. Does this mean that the callback function will not execute unless the daemon is in the running state?

If so, then the callback does not necessary run when the timer expires? (because the dameon cannot run). Is this true?

braunr wrote on Wednesday, November 21, 2018:

The exact semantics of practically any timer interface is that a timer runs at the expiration time or after. A timer may be delayed if a task with a priority higher than the timer task is running.

richarddamon wrote on Wednesday, November 21, 2018:

Since the callback is done by the Dameon, if the Dameon is being held back by a higher priority task, the callback will not run until the Dameon task does become the highest priority task. Think of it as the callback has a task priority of the Dameon task, because it does.