sys/ztimer/xtimer_compat: provide more fallback options

[benpicco]

Contribution description

The xtimer API can be used as a backend agnostic frontend to ztimer.
To better facilitate this (and also allow the use without a timer for simple sleep operations), add more fall-back implementations.

Testing procedure

Issues/PRs references

alternative to #19719

[Teufelchen1]

Uncrustify is pretty unhappy with this one ;)

[maribu]

I think the convention was to use IS_USED() with modules. We couod revisit this decision and do an s/IS_USED/IS_ACTIVE/, but rather in a dedicated PR.

We could discuss this in upcoming VMA and quickly vote on this.

[riot-ci]

Murdock results

✔️ PASSED

18c1754 ztimer_xtimer_compat: warn if backend != ztimer_usec

Success	Failures	Total	Runtime
10249	0	10249	16m:17s

Artifacts

• Documentation preview

[kfessel]

I like this (xtimer_compat is a nice interface to ztimer).

I just like to raise the question: "Could we somehow ensure that the user we somehow ensure the user knows about the mapping to ztimer_msec happening?"

• eg.: simply raise a warning and a pseudo module removes it

[benpicco]

What is that warning supposed to look like and what is it supposed to achieve?

The xTimer API is provided by ZTimer. This should have no influence on it's functionality, carry on and have a nice day!

[chrysn]

IIUC this is causing troubles with Rust builds – but riot-wrappers doesn't wrap (and doesn't plan to wrap) XTimer.

Does switching riot-sys in .cargo/config.toml to the branch of RIOT-OS/rust-riot-sys#51 solve the build issues?

[kfessel]

What is that warning supposed to look like and what is it supposed to achieve?

The xTimer API is provided by ZTimer. This should have no influence on it's functionality, carry on and have a nice day!

I thought of a warning in case of ztimer_msec providing the service for xtimer_usleep when it might have some influence on functionality

[benpicco]

Like so?