Feature request: Timer management API

[pizi-nordic]

The generic timer API provided by the Zephyr does not abstract low-level timer properties, which are essential in low power embedded applications. As result the user is not able to fully utilize hardware capabilities.

We can easily identify four key parameters of each hardware timer in the system:

• Resolution
• Accuracy
• Power Consumption
• Start-up Time

Depending on the use case and current system state a different timer might be used as a time source.
For example a simple Bluetooth application might use 3 different timers during normal operation:

• The low-frequency RC oscillator may be used during system wakeup, as it has minimal start-up time.
• When idle, a more accurate XTAL-based oscillator could be used to reduce power consumption (Bluetooth RX window might be shortened if accurate clock source is available).
• From time to time, when some activity is performed, a high frequency oscillator might be turned on in order to increase time base resolution.

This issue has been created as a generalization of #6498

Things needed:

• Abstraction of low-level timer properties (resolution, accuracy, startup time, maybe power consumption)
• Universal and precise abstraction of time (time cannot be stored in timer "clocks" as time base could change at any moment).
• API for selecting most suitable clock source in run-time.
• API informing subsystems about clock source change (BT will need this to adjust RX window).

[pizi-nordic]

CC: @carlescufi @cvinayak

[andyross]

Noting for posterity that such a feature is likely to interact in complicated ways with tickless kernel support, which in some sense speaks to exactly the same use cases and should be unified. Honestly tickless is a little bitrotten right now -- really we should be using it by default on most platforms where support is available.

[carlescufi]

@nordic-krch could you please check if this still applies?

[zephyrbot]

Hi @andyross,

This issue, marked as an Feature Request, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@pizi-nordic you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

[andyross]

Closing. It seems like most of the practical requirements here have long since been met, we have multiple architectures that can do clock switching across idle. We can always reopen to argue about design, but I think half a decade is enough time for this to have matured.