leesp wrote on Sunday, May 28, 2017:
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
richard_damon wrote on Sunday, May 28, 2017:
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.
hs2sf wrote on Sunday, May 28, 2017:
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.
rtel wrote on Sunday, May 28, 2017:
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).
leesp wrote on Monday, May 29, 2017:
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 timer_1 with period 10ms. The Systick is 1ms (configTICK_RATE_Hz = 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 timer_1’s timer value. So after 1st tick interrupt, timer_1’s value becomes 9. Then the daemon task would block. When the next tick interrupt happens, daemon task Run again and decrement timer_1’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?
hs2sf wrote on Monday, May 29, 2017:
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 
richard_damon wrote on Monday, May 29, 2017:
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.
richard_damon wrote on Monday, May 29, 2017:
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.
rtel wrote on Monday, May 29, 2017:
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.
leesp wrote on Tuesday, May 30, 2017:
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?
rtel wrote on Tuesday, May 30, 2017:
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.
leesp wrote on Tuesday, May 30, 2017:
Hi, I’ve updated my post… please kindly read again and advise. Thankyou
rtel wrote on Tuesday, May 30, 2017:
Please don’t edit posts, but add new posts to the thread. Now my
original reply doesn’t make any sense.
leesp wrote on Tuesday, May 30, 2017:
oops… sorry. I thought while I was updating the original post won’t be seen