Kernel MS Precision

Michael Rosen

Zephyr Devs,


Weve started moving our project from Zephyr 1.5 to Zephyr 1.7. One big change (aside from the really big ones like unified kernel and all that) is that the APIs for timers and others seems to have changes from taking in values in ticks to taking their arguments in milliseconds. For most applications, this is probably fine but in our case, its really unfortunate. We want to have a tick granularity of 500us (0.5ms) for our system so we can do operations at more precise timings (yes, at the cost of extra timer interrupts), and with the old API, that wasn’t an issue. Youd just change your units to microseconds and do things like:


nano_timer_start(&timer, USEC(1500));


To get a 1.5ms timer. Now, there seems to be K_MSEC and K_SECONDS to convert from “kernel time measure” as before (replacing just MSEC and SECONDS) but this is just a direct translation and the function itself does the transformation into ticks as the first thing it does. Is there a strong reason why the API was changed to prevent greater than 1ms ticks from being easy to achieve, especially considering users are expected to use K_MSEC and K_SECONDS anyway? I don’t expect any system to have a 1us tick, but just a 0.5ms tick is now impossible (without modifying the kernel code at least).







Join to automatically receive all group messages.