The arch_k_cycle_get_XX functions should be able to use counters API too

[avolkov-1221]

The current implementations of arch_k_cycle_get_32/64, very often used in pooling/profiling/benchmarking, are actually hardcoded wrappers around the system timer API call under the assumption that its resolution is the best in the system. However, this assumption is not always true, especially if the system timer is something like a RTC with a frequency of 32 KHz. However, there are often other higher resolution counters-like/counters device(s) in the system that can be used via the counters API, like for example, the optional DWT_CYCCNT counter of the ARMv7-M architecture.

My suggestion is to add a new system-wide call like sys_counter_cycle_get_32/64 and make it configurable with the board's DTS/Kconfig. Ie arch_k_cycle_get_32 will look like:

static inline uint32_t arch_k_cycle_get_32(void)
{
#if CONFIG_USE_SYSTEM_COUNTER_AS_CYCLE_SRC
       return sys_counter_cycle_get_32();
#else
       return sys_clock_cycle_get_32();
#endif
}

Or it might be better to add #ifdef/#endif around sys_counter_cycle_get_XX in the system clock drivers, as was done for arch_busy_wait() and implement sys_counter_cycle_get_XX() in the counter driver instead.

[henrikbrixandersen]

But the cycle count should match system timer frequency? Why not just implement a drivers/timer driver for the high-resolution "counter"?

[avolkov-1221]

But the cycle count should match system timer frequency?

The system timer ticks (not cycle) should be divisible by counter's clock, but I don't see any reason why the frequencies should match. The timeouts always defined in ticks, isn't it?

Why not just implement a drivers/timer driver for the high-resolution "counter"?

As has also been described in #61631, high performance timers/counters very often (AFAIK most of STM/Renesas Cortex-M chips) is stopped in the sleep/deep sleep state, so the chip can't wake up and, as hence, use very long timeouts. Or the counter is a real free running counter and have not interrupt line, like DWT_CYCCNT one. So you have only a choice: sacrifice power efficiency (usually unacceptable) and keep the CPU full throttle, or wait for milliseconds instead of nano/micro in pooling routines and have the worst statistics precision (and probably over-consumption too).

@andyross could you comment on this issue too?

[zephyrbot]

Hi @andyross,

This issue, marked as an Enhancement, 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.

@avolkov-1221 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!