Issues #7743 and #7332 both discuss the problem.
Dan
I saw those issues but they only refer to the fact that xtimer doesn’t run during sleep modes, is that the only issue? Cheers
Francisco
That's the 'only' issue. Problem: xtimer is guaranteed to have 1usec of resolution. Most low-power timers will only have 8bit resolution -> xtimer cannot be used.
First, I should add that I currently have a working samd21 low power implementation but to accomplish that I use rtt.c for my always running clock and then standby sleep the module whenever it gets to the idle task. This is a hack and is not a clean implementation and means you don’t use XTIMER and no use of the nice built in protocols, I have my own hacked LoRa mesh network.
Referring specifically to the samd21, which includes the samr21 and loosely the saml21, this is the path as I see it for getting low power working natively with RIOT:
- Add a method to make setting up the generic clocks that includes run in standby and on demand options.
- Add flags for peripherals so that you can set the clock and run in standby
- Tweak XTIMER so that it can be run by a low power 32kHz clock when sleeping
All of these things have been discussed and are in the works and are on the list but not currently top priority. Low power is critical for my application and I am a little surprised it isn’t for more users, but I imagine others just hack around it as well?
Hope that helps a little,
Dan
This is not quite true. Xtimer works fine with the ultra low power 32khz oscillator on SAMR21, it just needs a little reconfiguration. We have duty cycling nodes working ok with gnrc.
A little reconfiguration sounds like an understatement if you are truly going into standby sleep mode?
Dan
Hi,
I didn't say it is not working. But xtimer was designed to guarantee a
resolution of 1usec. Therefore if you use it with a different timer, you
are out of spec within RIOT 
We have two xtimer-like RTC-based timers implemented on STM32L1:
- https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers — rtctimers for ~1 second to 1 week delays, it uses regular RTC calendar
- https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis — rtctimers-millis for ~1 ms to 1 min delays, it uses RTC_SSR subseconds register (not available on some devices) and RTC calendar seconds register
- RTC_SSR driver implementation — https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32l1/periph/rtc.c
P.S. On STM32L1, regular XTIMER can not run from 32 kHz clock in stop or standby mode, as all TIMx timers need APB1 clocking. Switching xtimer to RTC clock will degrade its resolution.
Hi all
I for one have been missing support for RTC that would enable MCU sleep and wake up the system via ISR callback when requested. How about making a pull request out of this and make it part of RIOT? I’m seeing the copyleft licensing is LGPL so it should be good.
- t
Hi,
First, I should add that I currently have a working samd21 low power implementation but to accomplish that I use rtt.c for my always running clock and then standby sleep the module whenever it gets to the idle task. This is a hack and is not a clean implementation and means you don’t use XTIMER and no use of the nice built in protocols, I have my own hacked LoRa mesh network.
Referring specifically to the samd21, which includes the samr21 and loosely the saml21, this is the path as I see it for getting low power working natively with RIOT:
1) Add a method to make setting up the generic clocks that includes run in standby and on demand options. 2) Add flags for peripherals so that you can set the clock and run in standby 3) Tweak XTIMER so that it can be run by a low power 32kHz clock when sleeping
I am using xtimer with 32768 Hz clocking, on the Kinetis platform (PR: kinetis: Implement low power modes by jnohlgard · Pull Request #7897 · RIOT-OS/RIOT · GitHub). It's not an issue with xtimer itself, more of a question of high performance, 1 µs precision vs. low power, ~30 µs tick precision (but because of delays in the low power timer hardware it's more like 90-150 µs precision on my dev board). There are many applications where it does not matter if the timer delay is not exact, as long as it does not drift too much.
All of these things have been discussed and are in the works and are on the list but not currently top priority. Low power is critical for my application and I am a little surprised it isn’t for more users, but I imagine others just hack around it as well?
It's critical for most of our applications as well, but I have not had time to properly wrap things up in nice PRs. We have some coming projects which will need even more low power optimizations which should be upstreamed once they are working and we have had some time to clean it up.
Hope that helps a little,
Dan
Issues #7743 and #7332 both discuss the problem.
Dan
I saw those issues but they only refer to the fact that xtimer doesn't run during sleep modes, is that the only issue? Cheers
Francisco
Best regards, Joakim