roll-up issue for timer/clock enhancements

[pabigot]

This issue is a placeholder to track the progress of changes to the controlled delay and clock infrastructure of Zephyr to support a variety of needs identified in various issues.
See the TSC presentation for background.

• Improving resolution and usability of controlled delays in kernel APIs #17162 outlines the high-level concerns related to timeouts
• PR New timeout API #17155 proposed a framework for changing timeout representation to support better control and resolution
• PR New, orthogonal and complete time conversion API #19591 provides API for general conversion of values between time, tick, and cycle count domains with controlled rounding (extracted from New timeout API #17155).
• TBD identifies the task of generalizing the existing timeout infrastructure so it can be implemented with multiple back-end clock providers
• TBD provides a clock domain model that's used to derive the required behavior for (non-system?) clocks with respect to absolute/relative deadlines and order of execution of callbacks.
• [RFC] Abstract Clock Subsystem Architecture #19030 proposes an API for extending the supported clocks in Zephyr
• Milestones toward generalized representation of timeouts #19655 proposes a roadmap for this task

[lawrencek52]

I like the concept of making timeouts independent of milliseconds, great plan. I read through the APIs, and the fact that everything gets converted to local units at compile time makes this quite low overhead.

64-bit numbers are a little problematic, I noticed one issue with 64-bit numbers while working with the previous implementation of k_uptime_get(). It is hard to printout the numbers, in printk() the %lld and %llu formatters don't seem to work for 64-bit numbers. (as a side note shouldn't printk be k_printf?)

It would seem to me that you should include some support functions to convert the time numbers, independent of the storage format of k_timeout_t (32-bit, 64-bit, or structs with flags with 63, 63, 61 bit numbers, or whatever) into something human readable should be part of the package.

-Lawrence-

[pabigot]

@lawrencek52 Agreed. We've got lib/os/timeutil.c where such a feature could go once we (a) have enough experience to figure out what options it might provide, and (b) reach consensus on the subset it should provide.

[nashif]

most items resolved, remaining bullets do not have enough details or context, so closing. If needed, please open seperate issues with more details.

[ghost]

@pabigot I believe your concerns are now all addressed in #76335 as an umbrella RFC for everything that has been proposed around precision timing. But maybe you want to give the linked RFC a quick review? I'm now returning to implementing layer 1 and two of the proposed clock architecture, so this will be an active RFC with new PRs being linked to it in the future.