Open dcoles opened 5 months ago
Having a Furi specific Duration
/Instant
type that works on ticks seems to be quite useful, especially for some of the more low-level APIs. I wonder if we want to rename these FuriDuration
and FuriInstant
and provide conversion functions (e.g. FuriDuration::try_from(Duration)
).
Currently we have some APIs that use
core::time::Duration
(e.g.flipperzero::furi::thread::sleep
) and some that useflipperzero::furi::time::Duration
(e.g.flipperzero::gpio::i2c
). This isn't great since it leads to a rather confusing situation where you have two incompatibleDuration
implementations in scope.My understanding that the main reason that
flipperzero::furi::time
exists is that there is noInstant
implementation incore::time
and to better align with the kernel's tick resolution.A quick comparison:
core::time::Duration
flipperzero::furi::time::Duration
flipperzero::furi::time::Instant
{ secs: u64, nanos: u32 }
{ ticks: u32 }
{ ticks: u32 }
Consumers:
furi_delay_us(u32)
furi_delay_ms(u32)
furi_delay_tick(u32)
furi_hal_i2c_tx(..., u32)
[^1]: Assuming the default
configTICK_RATE_HZ_RAW = 1000