Clock with runtime defined SCALING_FACTOR about embedded-time

[PTaylor-us]

I plan to migrate to const generics when they're ready. That's what I wanted from the start, but had to settle for the associated const. I need to play with some code to understand more fully where the sticking point is. I haven't had a chance to use Rust for some time, so I'm a bit .... wait for it .... rusty :).

Thank you for your interest in the crate and I look forward to working with you to find a solution.

[PTaylor-us]

Then fn try_now should return the current ticks / Instant pretending it being a monotonic timer, and that is its only purpose?

That is correct. In this case to get the current tick value, it's triggering a linked capture and reading the two registers of a concatenated hardware timer on the nRF52.

Knowing the clock at compile time (especially out of the perspective of a library author) is a rare exception.

Setting aside the context of library author for a sec, in my experience, clock speed is always known at compile time. At the very least, it is known what it will be after startup configuration. It's been a while since I've been in Rust, but for a library, can't the user of the library define a const value that is used in the clock implementation?

[Sh3Rm4n]

Setting aside the context of library author for a sec, in my experience, clock speed is always known at compile time. At the very least, it is known what it will be after startup configuration. It's been a while since I've been in Rust, but for a library, can't the user of the library define a const value that is used in the clock implementation?

Yeah, this is something I have though about as well. I think the problem right now is, that the SCALING_FACTOR is set via a associated const, which means that only one clock per timer is possible (which might be okay for a user, but is not for a library author). So I guess a better solution could, that the SCALING_FACTOR is parametrized with const generics.

iml<const SCALING_FACTOR: time::fraction::Fraction>  time::Clock<SCALING_FACTOR> for SysClock {
    // ...
}

But this example, as written above, is not possible, as of the current min-const-generics implantation. So it might have to be dumped down to compile. So leveraging the fact, that the scaling factor is known at compile time to reduce overhead is definitely a great thing to thrive for, but it lacks flexibility right now (because of lacking const generics features - or because it is not dynamically configurable) to be used in a library.