Hello there,
I am trying to incorporate some basic power saving features in our design (STM32L452 MCU based). I am now trying to understand how does the tickless method work, and I am a bit confused. To be exact, I cant figure out what is the proper value of configEXPECTED_IDLE_TIME_BEFORE_SLEEP that I should use. The tick rate in my application is 1 kHz (value of tick 1 = 1 ms). Ideally, I was aiming for such functionality:
If MCU is idle for more than 1 second, go to tickless mode and sleep.
For this end, I set the configEXPECTED_IDLE_TIME_BEFORE_SLEEP to 1000. I have noticed however that the more i set this value too, the least often my program counter enters the PreSleepProcessing and PostSleepProcessing functions… I believe I simply dont get how this works.
In my application I can expect around 1 - 5 minutes of idle states periodically, but they can get interrupted by some external events.
From your post I think you may be misinterpreting what the value does.
It does not say, “if you have been idle for
configEXPECTED_IDLE_TIME_BEFORE_SLEEP ticks then enter tickless mode”,
but “if there is nothing predictable to do for the next
configEXPECTED_IDLE_TIME_BEFORE_SLEEP ticks, then enter tickless mode”.
As a simple example, let’s say you have one task that runs every 1000
ticks, something like:
Then every time the program enters vTaskDelay() the scheduler will know
the system has nothing to do for 1000 ticks (there are no other tasks
with shorter block times) so if configEXPECTED_IDLE_TIME_BEFORE_SLEEP is
set to 999 it will enter tickless mode to wait for 1000 ticks. On the
other hand, if configEXPECTED_IDLE_TIME_BEFORE_SLEEP is set to 1001 then
it knows it will have something to do before 1001 ticks have passed as
mytask() needs to run in 1000 ticks, so it will not enter sleep mode.
The reasons I said ‘anything predictable to do’ is because you can
receive an interrupt that brings the system out of sleep mode at any
time, the RTOS scheduler cannot know when that will happen in advance.
Hi Richard, thank you for answer. This clears some things up, thanks. I will test the functionality further and ask again in case I get cornered, but this should work now :).
The problem is the following: I have noticed that for my system, I can have no longer tickless perdiods than 209 ms. This is due to the fact that I am running 80 Mhz frequency and the SYstick timer is 24 bits. In the CubeMX software from ST, where one can generate initial code I chave changed the system timer from systick to TIM2 (32 bit). The problem is that the generated port.c file is completelly unaware of that timer change and still operates on systick everywhere, the register addresses are hardcoded.
For my application where I am expecting idle periods in minutes rather than ms, I would need a higher max value. It would fit perfectly in an 32 bit timer. What would you suggest here?
Hi Barry, thanks for the links.
This is interesting. At first glance it seems to me that the easiest way to go here is to reduce the clock frequency with which the SysTick timer is clocked. But are there any drawbacks of doing so?
Actualy, dropping the input clock rate on the systick won’t decrease block time resolution if you also drop the counter period value to get the same tick rate (which should happen automatically). You should make sure that the resultant frequency you drop it to still allows computing the tick period exactly (if you worry about that).
Thank you for answers Richards,
I also think that the counter period is updated automatically.
As for the resolution, I think its enough. Before reducing the frequency, there was 80000 cycles per tick, now its 10000 (80 Mhz clock). The FreeRTOS system resolution is still only 1 kHz anyways, unless I dont understand what you guys talk about exactly.
Yes, FreeRTOS’s resolution it the tick rate, which sounds like you have at 1 kHz/1ms. I tend to run my systems a lot slower, as I tend to not need that precise of time measurements, and a lower tick rate lets the machine idle more.
Yes, FreeRTOS’s resolution it the tick rate, which sounds like you have at 1 kHz/1ms. I tend to run my systems a lot slower, as I tend to not need that precise of time measurements, and a lower tick rate lets the machine idle more.
Indeed I am at the default 1 kHz/ 1 ms. On one hand its more than enough and on the other I know that I am ready for some more demanding features if needed.
So to summarize, there should be no real.drawback from tris clock reduction?
As long as the clock reduction factor still lets you get to exactly the right tick frequency, the drawbacks are minimal. I suppose the biggest drawback is that when the tickless code resets the timer you will lose the time corresponding to the prescaler, but since it also rounds of the time measurement to the nearest tick, that is small (it might be possible with additional code to make the first tick after resuming shorter to get back to close to the right tick alignment, but generally you can’t adjust for the loss in the prescaler as that isn’t measured),