Tickless idle and shared HW with task specific configuration?

turboscrew wrote on Saturday, November 04, 2017:

We are using STM32L4 family device with M4F-port of FreeRTOS 9.0.0 (GCC) in case it’s relevant…
The problem is that we have 2 tasks one of which runs for a couple of milliseconds approximately once per 100 ms and the other runs for about 5 ms once per about one second.

The tasks delay most of the time.
In out tickless idle the system is put to STOP2 mode and due to the clock setting overhead, the configEXPECTED_IDLE_TIME_BEFORE_SLEEP is set to 10.

The problem here is that we have a quite accurate but power hungry oscillator that is needed by the task running once per second, but not by the other task, so when waking up in the tickless idle we’d like to use the accurate oscillator, if the task requiring it is run, but use an RC oscillator if only the other task is to be run.

The tickless idle is a natural place for the clock switching, because then no task is doing any I/O that might be messed up by clock change, but it’s pretty hard to foretell if the task requiring the HSE is going to be run before the next tickless idle call.

Has anyone come across a good solution to this kind of problem?
At the moment I’m “recording” the accurate oscillator requiring task’s wake up time, and, at the wakeup, “guessing” whether or not there is another tickless idle call before that task is due.

richard_damon wrote on Sunday, November 05, 2017:

When I had something similar to this, I didn’t use the tickless idle routine for this, but created a clock-control ‘module’ that the various devices that can’t tolerate clock changes lock/unlock the ability to change the clock source, and the task that needs the special clock makes a request for the clock, and is blocked until the clock change has occured (and the various devices are asked to try to get to a point quickly where a clock change is ok), and then are told when the clock has changed so they can reconfigure for the different clock.

Onr thing that needs to be reconfigured is the tick interrupt to keep the rate close to constant, but there can be some time shift when you reconfigure it.

One thing that you do need to watch out for is that sort of by necessity, the task that needs the high power clock is going to be subject to uncertanty on when it can start its actions that need the special clock. In your case, if you can predict well when it will be needed, you can set the request a bit before it is needed so it will be ready when needed.

turboscrew wrote on Sunday, November 05, 2017:

Thanks. I guess I’ll go on with the way I’m doing it now, but next time I’ll use your way. It’s much more reliable.