Kernel high-resolution timer support

[carlescufi]

Several users in the mailing list have asked for highly precise busy-wait primitives that allow them to time with precision.

I don't know what sort of APIs we'd need, but at the very least something like:

k_hr_busy_wait(u64_t microseconds)

[carlescufi]

@anangl @tbursztyka FYI

[SebastianBoe]

In addition to a high-resolution timer API, I imagine users that have the high-frequency clock always-on anyway would like to be able to Kconfigure "_arch_k_cycle_get_32" to use the high-frequency clock instead of the low-frequency clock.

[diytronic]

Why only a microseconds resolution?
May be use same approach as system clock - using timer ticks?
Something like k_hr_cycle_get

[carlescufi]

@diytronic

Why only a microseconds resolution?

Agreed, I checked the Linux HR timer API and it uses nanoseconds.

May be use same approach as system clock - using timer ticks?

Well, there is also k_busy_wait(u32_t microseconds) now already in the kernel

[carlescufi]

@SebastianBoe

In addition to a high-resolution timer API, I imagine users that have the high-frequency clock always-on anyway would like to be able to Kconfigure "_arch_k_cycle_get_32" to use the high-frequency clock instead of the low-frequency clock.

Agreed, the only issue in the Nordic platforms then is that we'd need a secondary implementation of our system timer driver that uses a timer instead of the RTC.

[andyross]

Yeah, on systems with a high precision cycle counter, k_busy_wait() does what you want already. It just spins on k_cycle_get_32() as described. On essentially all the current platforms, k_cycle_get_32() is provided out of the timer driver as _timer_cycle_get_32().

Pretty sure you have what you want already, no?

[carlescufi]

@andyross yeah, I think so. Unless we really need nanosecond precision, but on current microcontrollers this make little sense actually, since the overhead in instructions would already clobber the added resolution.

@diytronic would that cover your needs, if k_busy_wait() was actually precise on Nordic platforms?

[diytronic]

@carlescufi For current task yes, but I am implementing 1-wire bus now (need it for ds18b20 sensor, so really writing driver for it too) and among the standard mode 1-wire has so called overdrive mode (faster). Here you can look at timings (just to make sure it is not my stupid caprice) https://www.maximintegrated.com/en/app-notes/index.mvp/id/126 So in overdrive mode it required for example 1us, 2.5us delays and so on. So on my opinion nanosecond resolution could be way better.

[diytronic]

@carlescufi BTW just checked for example CAN BUS timings https://www.nxp.com/docs/en/application-note/AN1798.pdf So nanosecond delays there. So I think nanosecond delay must be implemented.