Page 2 of 2
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 10:22 am
by ag123
Well, one way though, for timing critical apps, a hardware timer gives the best precision and predictability. That may be useful for timing sensitive apps such as interfacing a sensor over comms etc. But it would cost some power. And I'm not too sure how that works in deep sleep etc, my guess is the hardware timer should still be running as it is a separate hardware from the CPU.
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 11:28 am
by mebab
Thanks fpiSTM. The part of the code under discussion is in the following:
Code: Select all
uint32_t ss = millis() - T_Beginx; // SS is the total operating time of different tasks from the beginning of the main loop
uint32_t ww=0;
if (T_Loop>ss) ww = T_Loop-ss; // We check if there is an extra time left for energy saving; T_Loop =10000 ms
if ww>0 // In case there is time left, the processor will sleep to save energy
{
sleep(ww); // To sleep STM32 as much as ww
//LowPower.deepSleep(ww); // To deep sleep STM32 as much as ww
}
There are two problems:
1. Waking up of
LowPower.deepSleep(ww) instead of
sleep(ww) takes more than ww millisecond.
2. Assuming that ww is longer than 10 ms, the interrupt (every 10 ms) can not be carried out during deep sleep mode as you mentioned.
Because of above mentioned reasons I had to deactivate
LowPower.deepSleep(ww).
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 11:44 am
by mebab
ag123 wrote: ↑Thu Sep 23, 2021 10:22 am
Well, one way though, for timing critical apps, a hardware timer gives the best precision and predictability. That may be useful for timing sensitive apps such as interfacing a sensor over comms etc. But it would cost some power. And I'm not too sure how that works in deep sleep etc, my guess is the hardware timer should still be running as it is a separate hardware from the CPU.
The external RTC can help to have the correct real-time and it consumes up to 1 mA which is ok. But, problem is that I need the CPU to work while I read the sensors in every interrupt-based 10 ms. Then, my problem is how to force STM32 to deep sleep mode for short times like 10 ms repeatedly. Because, as I replied fpiSTM, the CPU doesn't wake up at exact times after being in deep sleep mode! Maybe this is not the case with long times like few seconds or so. The simple word is deep sleep is not working fine for short times.
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 12:04 pm
by ag123
You can experiment with hardware timers to see if those timer interrupts works in deep sleep modes. I've not tried such yet.
If those works, then it is a solution, as it can drive the interrupts at the frequency you need.
You may like to search app notes from ST to see if there are things about that.
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 12:53 pm
by fpiSTM
millis() relies on the systick. in low power mode systick interrupt is disabled so millis is no more increased.
About the RTC time, ensure to use the LSE as input for theRTC to have a better precision.
Then you ask for ms, this implies the subsecond usage which is fairly dependant of the RTC synchronous prescaler value. depending of the this value the subsecond match is more or less precise.
For example, with 255 as prescaler value the best possible is Alarm activated every 1/128 s -- > 7,8 ms (for RTC2 type, the one of STM32L476)
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 2:27 pm
by mebab
Thank you all for the valuable comments! I will consider using the external RTC later when my hardware is ready for the test which may take some time.
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 2:36 pm
by fpiSTM
And do not forget it exists some latencies due to sleep mode entrance and exit...
Re: Appropriate low-power mode for timing applications
Posted: Thu Sep 23, 2021 2:53 pm
by mebab
Yes. I know this. In fact, I have some extra reserve time at the end of the loop to take care of this.
Thanks for your kind help fpiSTM!