Anyone? Yes, I’ve tried reading the book “Mastering the FreeRTOS Real Time Kernel” but still don’t understand the concept. How is a “timer daemon task” related to say, vTaskDelay()? Please explain with a simple layman example (no need to show code). I have experience in bare-metal MCU “superloop” and interrupt-based programming so I should be able to grab the concept if explained properly. Thankyou

The timer daemon task deals with ‘Timers’ (see http://www.freertos.org/FreeRTOS-Software-Timer-API-Functions.html ) not time delays like vTaskDelay. It is also used so an ISR can request the exectuion of a small piece code at the ‘Task Level’ to avoid adding lattency at the interruupt level. vTaskDelay is used to make the current task wait a bit, maybe a delay to let things happen, or to put a delay in a task loop so you only check something periodically. A Timer lets setup a function to be called at a certain time in the future or at a defined rate. These functions should be short and fast, as all these functions will execute in the context of the Timer Daemon task, but can often be used to avoid the need to create a bunch of small periodic tasks. The also can be used as an asyncronous time out for an action. When you start an action, you start a timer. When you complete the action, youu stop and clear the timer. If the timer exprires, then the action didn’t complete in time, and the timer callback can initiate an abort for the action.

Software timers are realized by FreeRTOS with the timer daemon task. The timer daemon task does all the timer bookkeeping for you and eventually invokes the callback function specified on timer creation. A (normal) task may start a number of such timers and just continues to run. This timers can be seen as asynchrounous wrt. to the starting task. vTaskDelay is a synchronous sleep of the calling task ie. the task is directly moved from running into blocked state. The scheduler driven by the SysTick and wakes up the blocked/delayed task(s) after the number of ticks corresponding to the given delay. These are different concepts. In bare metal applications vTaskDelay is often implemented as a simple busy loop since there is no need to give up the CPU to allow other tasks to run. Software timers require more effort to implement.

The RTOS creates one or two system tasks – tasks that are created automatically when the scheduler is started for use by the RTOS itself. The first system task is the Idle task, which is always created. The second system task is the timer daemon task, which is also referred to by its older name as the timer service task. The timer daemon is created by the RTOS if configUSE_TIMERS is set to 1. The RTOS uses the daemon to manage FreeRTOS software timers, and nothing else. FreeRTOS API functions that start ‘Timer’ will somehow interact with the timer daemon task within their implementation (not seen by the application writer), and software timer callback functions execute in the context of the timer daemon task. Users can also send functions to the daemon task so they execute in the context of the daemon task rather than the application task. No other functions use the daemon task. So, using your example, the daemon task has no role in the execution of functions such as vTaskDelay() – and those functions will work the same even when the timer daemon task is not created (which would be the case if configUSE_TIMERS was set to 0).

I’ll try to explain what I understand, correct me if I am wrong: Timer daemon task is a handler task to the tick interrupt handler (a.k.a “ISR”) Say for example application programmer created and started a timer1 with period 10ms. The Systick is 1ms (configTICKRATEHz = 1000) At each tick interrupt, the tick interrupt ISR would execute, and then give semaphore to the daemon task to make it Ready. If now the daemon task is of highest priority, it will execute. Part of what the daemon task is doing is, to decrement timer1’s timer value. So after 1st tick interrupt, timer1’s value becomes 9. Then the daemon task would block. When the next tick interrupt happens, daemon task Run again and decrement timer1’s value.. so on and so forth. After 10 tick interrupt, daemon tasks finds that timer_1’s value is 0, and thus execute the callback function. Correct?

In principle you are right but the implementation is different. In fact the timer daemon task is just doing kind of vTaskDelay waiting for the next due timer to expire or another timer related request arrives (start, cancel, etc.). The SysTick ISR handler is the scheduler itself. If you’re really interested in all the gory details see timers.c. On the other hand you could just use it. It works 🙂

Actually, the Timer Daemon spends most of its time waiting on a queue which is used to send Timer requests, with a time out to for when the next Timer period will expire. The Timer Daemon doesn’t wake up on every tick, but only those which it has predermned that one of the timer will need to run.

Actually, the Timer Daemon spends most of its time waiting on a queue which is used to send Timer requests, with a time out to for when the next Timer period will expire. The Timer Daemon doesn’t wake up on every tick, but only those which it has predermned that one of the timer will need to run.

That’s right – the software timer implementation is very efficient and takes no CPU time at all unless a timer has actually expired. You have all the source code, and the timers.c file is quite small, it will not take long to see that your description of how it works is completely at odds to how it actually works.

I’ve tried reading timers.c Is prvTimerTask the so called timer daemon task? Looks like it is block on timer expiry, and command to arrive in the timer queue, as indicated in prvProcessTimerOrBlockTask, right? More questions: if I have created a timer1 with period of 10 ticks, Q1. Does it mean that, at a particular moment when prvTimerTask is executed, it checks the current timeNow and compared that to timer1’s tick; and if current timeNow is 6 ticks, then the daemon task will block waiting for command in the timer queue, with a timeout of 4 ticks?

Q1. Does it mean that, at every tick interrupt, timer1’s tick will decrement by 1?

No, processing each timer on each tick interrupt would be extremely inefficient. The timer daemon/service task enters the Blocked state until the timer is due to expire. Blocked tasks use no processing time at all, be that in the tick interrupt or elsewhere.

Hi, I’ve updated my post.. please kindly read again and advise. Thankyou

Please don’t edit posts, but add new posts to the thread. Now my original reply doesn’t make any sense.

oops.. sorry. I thought while I was updating the original post won’t be seen