I try this code on a thumbv7em-none-eabihf target:

defmt::println!("{:?}", TimerInstantU32::<100_000_000>::from_ticks(u32::MAX) > TimerInstantU32::<100_000_000>::from_ticks(1000));

Output:

0.099983 false

Since u32::MAX > 1000, something seems to be wrong inside of const_cmp?

remove existing const gcd implementation in favor of the GCD crate's implementation now that it provides it, and provide const into and try_into methods for converting between Instants of different fractions

Now we have 2 main ways to create value

1. DurarionType::from_ticks(val) - fixed type result, can be used in any context, but long call
2. Ext traits: 1.millis() - generic type result, non-const. Can fail to resolve result type if information is not enough.

Need short variant of 1 which looks similar to 2. cc @korken89

Currently I have something like this:

use fugit::{ExtU32, aliases::MillisDurationU32};

pub struct SysTimer{
    start: fugit::Instant::<u32, 1, 1_000>,
    duration: MillisDurationU32,
}

I would prefer:

pub struct SysTimer{
    start: fugit::Instant::<u32, 1, 1_000>,
    duration: fugit::MillisDurationU32,
}

Actually maybe it makes sense to create aliases also for Instants?

Since fugit already supports rendering nanosecond timebases, perhaps we could include nanoseconds alongside microseconds etc. Nanoseconds are used for PTP times so it would make working with them more convenient.

By the way, I added .gitattributes to make merge conflicts on CHANGELOG less likely; union means it will try and combine lines from both commits if possible which should do the right thing on a changelog. Happy to take this out if you want, of course!

Implements +=, -=, *=, and /= where appropriate, by using the existing +, -, *, and / operators.

This allows for example:

let mut t = MillisDurationU64::millis(100);
t += MillisDurationU64::millis(900);

instead of what's currently required:

let mut t = MillisDurationU64::millis(100);
t = t + MillisDurationU64::millis(900);

Sorry if this has been considered before, I couldn't find any previous discussions. I tried to add it wherever it makes sense alongside an existing operator implementation.

One of the last few commits, just prior to release of v0.3.3, has started giving me compile errors

   Compiling fugit v0.3.3
error[E0658]: panicking in constants is unstable
  --> /home/paul/.cargo/registry/src/github.com-1ecc6299db9ec823/fugit-0.3.3/src/helpers.rs:48:32
   |
48 |     pub const GREATER_EQ: () = assert!(L >= R);
   |                                ^^^^^^^^^^^^^^^
   |
   = note: see issue #51999 <https://github.com/rust-lang/rust/issues/51999> for more information
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

Any ideas?

This relates to #36.

While the correct fix for #36 (if any) seems to be controversial, let's first document how the functions work in their current form.

I was worried this might lead to overflows when doing something like

Duration::<u32, 1, 1_000_000_000>::from_ticks(1_000_000_000).to_nanos()

because it's working out

(1_000_000_000u32 * 1_000_000_000u32)/1_000_000_000u32

but in practice it seems to do the right thing (and I cover this case with tests).

In any event the maths is exactly the inverse of the existing micros() etc methods, so I guess it should work or fail in the same ways.

Currently Display is implemented for Duration: https://github.com/korken89/fugit/blob/master/src/duration.rs#L428-L448

I guess there isn't any drawback if Format is also implemented?

What do you think about defining type aliases like type MillisDuration<T> = Duration<T, 1, 1000> (or similar) to cut down on typing and mental load? Or even MillisDurationU32 to simplify it even more?

use of wrapping_add where the bases are equal, here: https://github.com/korken89/fugit/blob/master/src/instant.rs#L171 and similarly if bases are different, here: https://github.com/korken89/fugit/blob/master/src/instant.rs#L181

claim that it checks for overflow, here: https://github.com/korken89/fugit/blob/master/src/instant.rs#L156

evcxr transcript showing that it wraps:

>> :dep fugit = "0.3.6"
>> fugit::Instant::<u32, 1, 1000>::from_ticks(0xffff_ffff) + fugit::Duration::<u32, 1, 1000>::from_ticks(10)
Instant { ticks: 9 }

The implementation impl<const NOM: u32, const DENOM: u32> Ord for Instant<u64, NOM, DENOM> (and same with u32) doesn't comply with the specified requirements for implementations of Ord.

Ord requires the comparison to be transitive, ie. a < b and b < c implies a < c. (see https://doc.rust-lang.org/std/cmp/trait.Ord.html#corollaries)

However the current implementation tries to handle wrap-around of the underlying ticks counter: https://github.com/korken89/fugit/blob/master/src/instant.rs#L55-L70. That breaks the mentioned requirement.

So either the implementation should be changed, or Instant should not implement Ord (and neither PartialOrd).

I noticed this when trying to find the minimum in a list of Instants, and getting inconsistent results.

I'd like to have a small mdbook for fugit showing how to use it. There is enough const generics shenanigans that would be great to have examples for, as reading the code is ... not trivial.

If anyone feels like helping here, even just setting up the structure, I'd greatly welcome it!

It appears to me that it should be well possible to implement this conversion -- it wouldn't be as compile-time constant as the rest of fugit, but it would help gluing it to more generic code that works with standard, aeh, core durations.

(I'm considering to move my bespoke timers for RIOT-OS to just be a newtype around, and after the next breaking API change, just a type alias for fugit's duration, in particular TimerDurationU32, but don't want to lose functionality for simple demos whose values are expressed in what the user may be familiar with).

[edit: When I do switch over and there is soft approval of this, I can probably provide an implementation PR.]

As a general purpose time library, it would be nice to also support picosecond timebases. These arise frequently in time-to-digital conversion (TDC, whiterabbit, ToF, OTDR) or other high accuracy measurement (time/frequency metrology). The stuff in helpers.rs would need a u64/u128 versions.