time-driver and tick-hz selection is difficult and often incorrect

[d3zd3z]

Our zephyr crate provides a feature time-driver that provides an implementation of embassy-time's time driver. However, this functionality requires a tick rate to be set for the clock.

Zephyr supports fairly widely diverse tick rates, as does embassy-time. The challenge is getting them to the time driver. Right now, the tick rate must be set in Cargo.toml, which makes it uncorrelated with the actual tick rate. I could detect this, and possibly even fail at compile time (both are constants), at least forcing the user to set them correctly, but then any tests would fail to build across multiple targets.

Another suggestion was to set the tick rate to something like 1Mhz, and do conversions whenever converting to/from a Zephyr tick. Unfortunately, this can be challenging as the Zephyr tick values are fairly diverse (one target uses 993Hz, most are powers of 2, or small-factor multiples of 10).

Thoughts would be helpful.

[aolowin]

I would prefer to fail noisily. In my experience clock drift ends up adding all sorts of artifacts, especially if you're trying to correlate sensor data.

For tests would it be possible to have a predefined set of [feature]s for the various targets?