Finomnis

@deltronix Are you sure that this would really be helpful for your usecase? I had the impression that scheduling overhead and similar already introduces noise of multiple ticks, but maybe...

We could provide a higher resolution alternative that can be enabled via a feature flag, like we have for the `systick` monotonic. What resolution do you have in mind? As...

@burrbull I have the same problem on imxrt the other way round. The monotonic we have can take any clock source but it's fixed to 1MHz; it would be useful...

Another solution would be to move all of the monotonic code into macros that the user has to instantiate somewhere. Yet another solution would be to avoid the static nature...

So I did some measurements. I used the following code on an nrf52840 on a 1MHz monotonic: ```rust #[task(local = [led])] async fn blink(cx: blink::Context) { let blink::LocalResources { led,...

Ah, for reading the time. I get that usecase. Sadly it would require a major rework :/

Should get solved by #874, once merged. This makes monotonic tick rates no longer hard coded, so you can go as high as the hardware allows.

Might collide with and/or become obsolete through #874.

**EDIT:** I assume you are talking about RTIC 2. Yes, it is ok. If a spurious interrupt happens, RTIC will simply re-check the timer queue and do another `set_compare`. *"need...

@korken89 Hey! Sorry for the delay, I was kinda busy with family and stuff. I'll start working on this now again, looking forward to your feedback.