dirbaio[m]: > <@dirbaio:matrix.org> there's definitely interest indeed, the problem is it's very unclear how to do it. Decisions that must be done is:
> 
> - Bit width. Hardcoded, configurable via Cargo features, configurable via generics?
> - Tick rate: Hardcoded, configurable via Cargo features, configurable via generics? Const generics? typenum? Just a frequency value? or a full NUM/DENOM fraction?
> - Who gets to choose these settings? the HAL implementing the trait, or the driver using the trait? 
> - Single global clock, or multiple clocks? If multiple clocks, can they have different settings?
> 
> Example 1: embassy-time: 
> - bit width: hardcoded to u64, so it never overflows. (prioritizing convenience over efficiency)
> - tick rate: configurable via cargo features. Some HALs choose it, some let the end user choose.
> - Single global clock, so you can do `Instant::now()` from anywhere without having to pass around stuff.
> 
> Example 2: fugit
> - bit width: configurable with generics
> - tick rate: full NUM/DENOM fraction, configurable with const generics.
> - Who chooses? the HAL implementation (I think the HAL can choose to be generic so the end user chooses? but either way the driver can't choose)
> - Multiple clocks, each can have its own settings.
> 
> as you can see they're polar opposites.

- Bit width: configured by generics. I see the sconario as "hey, I need an embedded-hal expression of reading of my clock counter that is at 80MHz, and counts in a 32 bit register. it's going to be a clock, configured to 32 bits, and 80MHz
- tick rate: same again as bit width
- settings: Same as with `InputPin`: The trait defines a common interface. how it is configured, and its settings, is usually determined by the platform hal implementor, but there's nothing stopping some rando person from rejecting it and implementing their own.