RIOT-OS
sys/ztimer/xtimer_compat: provide more fallback options
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
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.
Murdock results
:x: FAILED
9b93f14963bc066d1c71bfb6b23f304ae7f74f6d fixup! fixup! fixup! Update sys/include/ztimer/xtimer_compat.h
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 10515 | 0 | 10873 | 08m:03s |
Artifacts
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
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!
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 https://github.com/RIOT-OS/rust-riot-sys/pull/51 solve the build issues?
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