Dynamic clock frequency

fjrg76 wrote on Thursday, July 18, 2013:

It has been three years when that same question was made:


At that time Richard said that there wasn’t so many people interested in the topic. Three years later, power-savings is a big concern for a lot of engineers.

Changing the clock frequency as the system is running makes a lot of sense, and virtually all microcontrollers are able to run from different clock sources:

1.- From very innacurate low frequency internal clock (the one used for the watchdog, for example)
2.- From an accurate RC internal clock
3.- From an accurate external 32KHz (RTC)
4.- And the king of all, external high frequency and very accurate crystal based oscillator.
(5.- And all of them

So it would be nice to move from one source to another as the power requirements dictates. The (any) RTOS should adapt to the application, and not in the opposite direction.

As far as I know the newest FreeRTOS feature towards power-saving is the tickless one, that in its own is a big step.

So the question is: FreeRTOS has a mechanism that follows any dynamic clock frequency change?

Thank you!!

rtel wrote on Friday, July 19, 2013:

It would still be tricky to achieve this because of the way FreeRTOS manages Blocked lists , but simplified greatly if there was the restriction that the tick frequency had to remain constant as the underlying clock frequency was changed dynamically.  Therefore, each time the clock frequency was changed, a function would need to be called that re-configured whichever peripheral was generating the tick interrupt, or switched to a different peripheral to generate the tick interrupt, to ensure the clock change didn’t result in a tick frequency change.

Here is the reason it would be tricky (although I like a challenge) if the clock change were to result in a tick frequency change:

Some RTOSes (that care less about performing non-deterministic list walking each time the time changes than does FreeRTOS) store block times as a counter that is counted down on each tick.  When the counter reaches zero the task is moved out of the Blocked state.  This is a crude method, but does allow for dynamic clock frequency changes as the Blocked tasks are served on each tick and the clock frequency known on each tick.

FreeRTOS does however have a policy of never performing non-deterministic actions in interrupts, and so instead places Blocked tasks in their wake time order.  Therefore only the front of the list needs to be examined in most tick interrupts.  You can see then that if a task wanted to unblock in 100ms time, and set an unblock tick time accordingly, only to have the number of ticks that made up 100ms change while the task was blocked, the task would be moved out of the Blocked state at the wrong time.

If the tick frequency were to half due to a clock change, then it would be possible to increment the tick count by two on each tick to ensure the time base as seen by the tasks didn’t change, but the RTOS would still need to be informed that it needed to do that using a new API function.

It is an interesting topic.  If this is a big deal for you, and you think also other people, then please add it to the feature request tracker in SourceForge.


fjrg76 wrote on Tuesday, July 23, 2013:

I do agree in the sense that, for now, the best option is to scale the system frequency down accordingly to the tick system,

Thank you!!