Monotonic / timer queue doesn't seem to support clock wrapping about rtic

[korken89]

Hi, thanks for reporting.

This does not look like a bug to me. RTIC simply requires some operations to be supported on Monotonic::Instant and Monotonic::Duration for it to be valid.
In this case you are using fugit as the underlying time library, whose Instant represents a wrap-able time.
So any Instant is valid MAX/2 - 1 ticks around it. This means that your example is correct behavior, as the the new instant is within the correct span for a valid instant:

fugit::Instant::<u32, 1, 1000>::from_ticks(0xffff_ffff) + fugit::Duration::<u32, 1, 1000>::from_ticks(10)
Instant { ticks: 9 } // Correct

On the old book chapter you found, this is not valid anymore.
It was for RTIC 0.5 and the Monotonic trait replaces the old method.

Is there anything else you'd like to ask or that I should clarify?

[Dridus]

to clarify, it's correct behavior that tasks might be executed either immediately (if now + delay wraps) or at the intended delay ± jitter, not delay ± jitter?

[korken89]

Sort of, it does not depend on wrapping - just if the instant is in the future or in the past.
So if an instant is in the past the task will be executed immediately, else it will be scheduled.
With fugit this means that you can represent time that is MAX/2 - 1 ticks into the future or the past compared to a specific Instant.
The library does the needed math to make this happen.

[perlindgren]

In principle jitter cannot be negative (besides the jitter of the HW timer). There is also a difference between a task being "released" (ready to run), and the actual execution. This may cause accumulated drift if using "now" as the timebase.

[Dridus]

Sort of, it does not depend on wrapping - just if the instant is in the future or in the past. So if an instant is in the past the task will be executed immediately, else it will be scheduled. With fugit this means that you can represent time that is MAX/2 - 1 ticks into the future or the past compared to a specific Instant. The library does the needed math to make this happen.

But you can't represent a time up to MAX/2-1 ticks into the future relative to any specific Instant though correct? Only relative to Instant 0, otherwise it's ambiguous whether it was intended to be in the past. I think it's surprising that spawn_after / reschedule_after might end up being basically the same as spawn, depending on the current value of the clock and what duration, since the addition with wrapping is hidden in the implementation of spawn_after / reschedule_after.

In principle jitter cannot be negative (besides the jitter of the HW timer). There is also a difference between a task being "released" (ready to run), and the actual execution. This may cause accumulated drift if using "now" as the timebase.

Ah yes good clarifications, I wasn't accurate.

---

Overall the behavior makes sense once one knows of all the details and limitations. I do think it'd be nice to be less surprising, either by documentation or better yet some indication from the API that wrapping/as-soon-as-possible execution might occur rather than duration + jitter.

As it stands it also makes for potentially complicated calling code if one really does need the proper wait. I can't judge whether it's important often enough to justify updating the implementation to support it automatically though.

[perlindgren]

By extending the Monotonic timer to a u64 store, duration will be large enough for (all) practical use cases, and solves the original issue. Please re-open this issue if further clarifications are needed.