Description
Rough idea/placeholder for discussion.
Motivation:
Currently Systick is used for triggering timer events. While this is a viable approach it comes with some cons.
- Systick is only 24 bits, causing OH in case the next message lies further into the future than representable by 24 bits. (Some architectures may allow for dividing the core clock, which could extend the "horizon".)
- Using a single "tick" source, we can have only a single timer queue. The timer task executing on behalf of a message to be dispatched at lower priority than the "tick" source causes interference (sort of a priority inversion) to the system.
- The complexity of insertion to the (single) timer queue is log n + some, meaning larger n gives higher cost.
Idea.
Allow for multiple timer queues and a Timer trait for the "tick" implementation. These are two separate issues but not orthogonal, since to implement multiple timer queues we need multiple timers (and to that end we need a Trait based approach, as RTFM is device agnostic.
It would also allow for the trade off between range and precision. E.g., a 32 bit timer, with a pre-scaler to the core clock of 2^16, would give us a 48 bit range (compared to core) with a granularity of 2^16 (compared to core). This could be very useful messages postponed far in the future, for which the granularity will be sufficient. In combination with low-power modes (wfi) this can save energy. One could even think of RTC based implementations of the Timer trait, allowing for deeper sleep modes (but I think we defer that to another "issue", as wake-up would likely require special handling.) On systems with only 16 bit timers (like the ST L0:s), pre-scaling and higher granularity in combination is already in the works.
Syntax:
Multiple timer queues would require some additional information passed to app. In a first step one could make the binding of schedule to identify the Timer implementation. (In the long term, one could think of giving a free list of Timer implementers, and for RTFM to do the best fit assignment of message queues (and set the pre-scaling for each timer), based on timing requirements for the messages. (But this requires additional information/syntax extensions, this will go in a separate "issue" as well.)
References:
For the original C implementation of RTFM, we made some initial experiments with Abstract Timers and Their Implementation, exploring (some of the) potential improvements.
http://ltu.diva-portal.org/smash/record.jsf?pid=diva2%3A1013030&dswid=-513