I wonder why FreeRTOS does not support real tick-less mode?
It should be possible to completely forget about the tick timer which is firing periodically, even when not needed. This only wastes power and fires useless interrupts.
When a timer is needed, e.g. for vTaskDelay() or simular it would be sufficient to setup a single HW timer for the next closest expiring time when more timers are active. When this timer fires a interrupt is called which probably wakes the mcu and the OS could generate a timer event as normal. No need for a tick timer which counts down to implement a vTaskDelay().
The only back draw would be that FreeRTOS feature configUSE_TIME_SLICING is not possible. But this feature is actually only needed for tasks running continously at same priority and will there never block. Then a round robin scheme will schedule between these continously runnings task. At pure event driven systems this is not needed at all.
Currently FreeRTOS supports only “tickless idle” which means that the tick timer is stopped when all tasks are blocked for a certain amount of time and is started again when a task gets ready for run.
Much more simplier OS like Contiki does this already, why not FreeRTOS?
There are pros and cons of doing it either way, and the tickless idle
method was chosen for the following reasons:
As you already noted, time slicing won’t work if the OS is always
tickless. Many years of experience has shown us that only expert users
who understand the consequences should turn time slicing off (and we do
not consider just running every task at a unique priority so time
slicing is not needed a reasonable restriction to put on people, for RAM
consumption and design flexibility reasons).
It is difficult to keep re-programming the clock without slippage
between the RTOS system time and calendar time.
Under heavy load it is simply more efficient to use a fixed
per-calculated time period than to re-calculate a time period each time
the scheduler runs and then re-program the clock.
Using the tickless idle mode CPU cycles are dedicated to saving power
only when it is possible to save power, that is, when it is known
nothing wants to run.
It is very common for people to add their own code to the tick
interrupt using a tick hook.
The implementation covers more use case scenarios (FreeRTOS is
probably used in a more wide number of use cases than Contiki).
Backward compatibility with old versions of FreeRTOS.
Probably other reasons too, the decision was taken quite a long time ago.
many thanks for your fast and comprehensive answers. Although I understand your argumentations and concerns, I would appreciate to have at least the option to turn on full tickless support for experienced users.