Implement TimeInt for unsigned ints

[TheZoq2]

I'm trying to port our current time unit types in stm32f1xx_hal to use this crate. Ideally, We currently use u32 as the inner type for our types, which I think makes sense since negative frequencies, or durations to wait for a timer for example don't make much sense.

It looks like the TimeInt type requires From<i32> and Into<i64> to be implemented for the inner type. Is there a reason for that?

[PTaylor-us]

This is a very good question and one I wrestled with for a while. I documented my self-discussion in #7. I would greatly appreciate if you would read that and let me know if my conclusion is incorrect or if there is a way to at least be compatible with unsigned inner types.

[TheZoq2]

Hmm, my motivation for specifying timings using this crate would be that, in theory, embedded drivers and HALs can use one unified time type to specify requirements. For that, no arithmetic is required, in fact, I'd imagine both the drivers and HALs would "unwrap" the types when arithmetic is required.

I may also be missing a use case, or perhaps this isn't the right crate for that job

[PTaylor-us]

@TheZoq2

embedded drivers and HALs can use one unified time type to specify requirements

I'm not exactly sure what you mean by "specify requirements". I can definitely see the nonsense of negative frequencies. I could see that if a duration is calculated, it may be negative. In many cases, however, durations are literal and so probably very seldom be negative.

I am willing and eager to make any changes necessary to enhance usability and compatibility. If I understand correctly, the only use-case you have currently is durations and frequencies and not the Clock trait or Instant types. I can definitely see how usage of durations and frequencies would be more common and the use of signed inner types add complications.

Let me look into this. Also, if you have any suggests, I'm very open to them.

[TheZoq2]

I'm not exactly sure what you mean by "specify requirements". I can definitely see the nonsense of negative frequencies. I could see that if a duration is calculated, it may be negative. In many cases, however, durations are literal and so probably very seldom be negative.

In the current embedded-hal, the type of a delay/duration is fully generic, so there is no neat way for a driver to be written to accept a specific value. This comment from a crate of mine describes it a bit better https://github.com/TheZoq2/esp01-rs/blob/master/src/timing.rs#L4. Because of the current design, there is no way to say "delay for 5 seconds", for example.

If I understand correctly, the only use-case you have currently is durations and frequencies and not the Clock trait or Instant types.

Precisely

[PTaylor-us]

@TheZoq2 I was able to change all the inner types to unsigned while maintaining the proper math concerning Instants. I would greatly appreciate it if you have a chance to take a look and see if this gives you the functionality you're looking for.