Description
Couple of months ago while working on tickless sleep mode we faced couple of issues around implementation of low power timer:
- accuracy
- working mode
- availability
and sleep:
- wake up time
- availability
It's a mixture of platform differences and no clear requirements for ticker and sleep implementation for targets in mbed.
To address that I'm proposing introducing an extra timer, which would be an alias for one of the existing timers (eg LP timer) and sleep mode, with clear implementation requirements (enforced by tests). Targets wishing to support tickless sleep mode, will need to declare TICKLESS capability and implement the tickless timer and sleep mode.
Tickless timer and sleep will need to conform to following requirements:
- Clock:
- needs to stay up during tickless sleep
- Resolution of less than 1ms (?or maybe at least driven of 32k crystal?)
- Sleep
- Needs to be able to wake up of the tickless timer
- Needs to wake up in given time (?microseconds?)
Having a implementation on different targets conforming to above specification would mean that we can have one coherent tickless implementation that works on majority of boards. To assure that all targets declaring TICKLESS capability actually fulfill the requirements we would implement tests, checking the clock resolution and accuracy and also ability and latency of waking the board up from associated sleep mode.
As a alternative, more generic, solution we could drop the new timer alias and define official requirements for the different timers and sleep modes that most platform implement already. That would help us maintain consistent behavior across the boards and features.
Downside of this proposal is that not all targets could implement timers/sleep modes as dictated by our requirements, which would lead us to either relaxing our specification or not implement given feature for some platforms.
Maybe hybrid approach would be the best solution, define rather relaxed but mandatory requirements for timers and sleep modes so we achieve some level of consistency. On top of that define strict requirements for extra features or capabilities (like tickless mode), which could be simple aliases for existing implementation or more complicated constructs.