xtimer: introduce xtimer_msleep()

[benpicco]

Contribution description

Add a function that sleeps for ms instead of µs.
This will make the conversion to ztimer easier for users as now there is a direct mapping to ZTIMER_MSEC.

Testing procedure

Issues/PRs references

[kaspar030]

This will make the conversion to ztimer easier for users as now there is a direct mapping to ZTIMER_MSEC.

btw, there is a coccinelle script that can recognize "xtimer_(, ..., foo * MSEC_IN_USEC)" and convert that to "ztimer_(ZTIMER_MSEC, ...)".

[benpicco]

btw.: what was the rationale for having ztimer_sleep(ZTIMER_USEC, …) instead of ztimer_usleep(…), ztimer_msleep()?

[maribu]

btw.: what was the rationale for having ztimer_sleep(ZTIMER_USEC, …) instead of ztimer_usleep(…), ztimer_msleep()?

I cannot answer what the rationale was, but I can point out some advantage of this decision: This decouples the choice of the hardware to run on from the time unit used.

E.g. let's say I have a PTP clock an a periph_timer. Both could implement ZTIMER_USEC. But I might want to provide both. E.g. setting a 1 second timeout on the periph_timer is guaranteed to actually trigger in 1 second (+- jitter, overhead, clock drift, ...). But if I set on on the PTP clock, it might trigger on something completely different due to clock synchronization.

E.g. in a sensor netowrk I might indeed want measurements to be performed completely synchronized, so in terms of the synchronized PTP clock - even if the period changes whenever the clock is adjusted.

[kaspar030]

btw.: what was the rationale for having ztimer_sleep(ZTIMER_USEC, …) instead of ztimer_usleep(…), ztimer_msleep()?

What @maribu said. ZTIMER_USEC is just a name (ptr) that by convention points to a ztimer clock that provides usec ticks.
While adding ztimer_usleep(val){ztimer_sleep(ZTIMER_USEC, val);} would be trivial to add, IMO as is this provides a lot of flexibility. E.g., all the ztimer tests can trivially be used to test any ztimer clock, because the clock argument is just a variable.

[maribu]

Being honest, I think that

xtimer_msleep(3);

is simply more readable than

xtimer_usleep(3 * US_PER_MS);

Just for that reason, we should IMO get this in.

That this will make people using ztimer_xtimer_compat more happy is of course also nice :-)

[fjmolinas]

Just for that reason, we should IMO get this in.

+1

[jia200x]

Just for that reason, we should IMO get this in.

+1

[maribu]

This would IMO now justify an ztimer_msleep() as helper - for when the user really doesn't care on which hardware the timer is set. But that should be another discussion in another PR.

[kaspar030]

why not just depend on ztimer msec?

[kaspar030]

the helper would do the intermediate wakeups N times for N ztimer_msleep instances. ztimer_sleep(ZTIMER_MSEC, ... would mitigate that.

[maribu]

Hmm, is there a use case for using ztimer without ztimer_msec?

[kaspar030]

well, if nothing uses it, no need to include it. but that's not the point here, there's no case (or there should not be one) where ztime_msec is not available.

[maribu]

ACK. I really like _ztimer_sleep_scale(), which should improve both readability and the opportunities of the compiler to optimize the code.

[kaspar030]

I really like _ztimer_sleep_scale(), which should improve both readability and the opportunities of the compiler to optimize the code.

yeah. maybe move it to be a public ztimer function?

[benpicco]

Hm now I wonder: will this now have a worse overhead than calling xtimer_usleep(ms * US_PER_MS) because here 64 bit arithmetic will be involved?

[maribu]

Rather than worrying about xtimer, let's push ztimer forward :-)