Ambiguous use of TICKS_MAX in time.ticks_diff and time.ticks_add given the time.ticks_ms has different resolution from _us and _cpu and it could cover different ranges in time and values
https://docs.micropython.org/en/v1.20.0/library/time.html
Scenario:
user uses ticks_ms() reads the docs about TICKS_MAX and the rolling over part... learns that he has to use ticks_diff() and ticks_add() to work with the values properly.
BUT
ticks_us() is described as: "Just like ticks_ms() above, but in microseconds."
The issue is, that it is not clarified if TICKS_MAX is the same (or not) for ticks_ms than ticks_us (maybe it should be TICKS_MAX_MS and TICKS_MAX_US and TICKS_MAX_CPU).
If the TICKS_MAX is the same for us, ms and cpu variants that means the maximum time interval these functions handle are wildly different, and this needs to be clarified. (Also there should be a lower bound to this say it won't roll over for "at least a second" to design the application for)
If the TICKS_MAX is different for ticks_ms() and ticks_us() (and ticks_cpu()) then there should be a different ticks_diff_ms() and ticks_add_ms() and ticks_diff_us() to properly handle the difference.
Based on the current text in the docs one could ASSUME that TICKS_MAX is the same for all three resolutions available, but it is not explicitly declared. Also this might not be true in the future. So maybe adding ticks_add_us() and ticks_diff_us() would be beneficial even if they are the same in all current implementations.
Feat nrf ticks support
This is a follow up / replacement of https://github.com/micropython/micropython/pull/5470
It supports time.ticks_ms(x), time.ticks_add(x) and time.ticks_diff(x) for two configurable timebases:
- Ticker timebase (1MHz), precise, app 5uA, 32bits
- RTC timebase (32kHz), less precise, app 0.5uA, 24bits
both are capabale of running in WFI low power mode (in contrast to the SYSTICK module)
see above link for further discussions / insights / thoughts).