IIRC they impose a delay of up to 6 slow clock ticks for every read or write to the RTT registers.
6 slow clock ticks at 32khz mean ~180us
during the synchronization, the bus is blocked_ (nothing on the bus can interact with the system. that means practically, most peripheral ISR are blocked)
(read can be “cached”, resulting in instant read of the value, which is then between 0-5 ticks “old”).
with current periph_rtt (used by ztimer), a set() requires a read and a write, so two syncs minimum. I think ztimer might even do a read or two more
IMO this makes the RTT so slow as to be unusable for many use-cases.
I propose we brain storm a bit on how to deal with it. Ideas?
Maybe synchronize some timers. E.g., if the board wakes up because of an RTT isr, assume it’s the previously set wakeup time. From then on, use a converted high freq timer.
Only before entering sleep the next time, set() the RTT once and store the expected wakeup time.
Some brainstorming won’t hurt, so here are some of the things that pop up in my mind:
How bad the impact of (1) is, absolutely depends on the platform (and its config).
Completely blocking the bus (2) sound really bad for many scenarios. The caching/shadowing combined with synchronization could be applicable to mitigate that. Do you know if in this particular case the 0-5 ticks age is deterministic as in “sync every 5 ticks, then it just gets older till the next sync” or is more like random ?
In any case: its not a property that is directly tied to the RTT API itself so we need some other way to store and communicate this information to decide case-by-case.
this case-by-case problem is one aspect that made me think it would be nice to push these decisions to the inside of the timer abstraction (or some utility function of it).
A more simplified lazy alternative could be to just define higher thresholds on when using RTT is deemed reasonable.
The underlying problem of varying hardware performance and limits is something we want to reflect with a property access for the envisioned low-level timer API. I think Niels is heading to dump details on that very soon…
One of the next steps after collecting and properly defining all these relevant metrics and culprits (of which there are many) we plan on doing micro-benchmarks to measure such performance implications. That should help to decide what is possible on which platform.
Maybe synchronize some timers. E.g. (…)
Yes. Probably not trivial but worth a try. Pretty much what I already said here
