This is a temporary fix for Issue #17060. It allows to disable
auto inclusion of `ztimer_periph_rtt` in cases where another
module or application requires direct access.
Limitations:
- as ifeq are involved order of inclusion matters, therefore
these modules should be included early in the build at application
level and not in modules `Makefile.dep`
- this does not disallow direct inclusions of `ztimer_periph_rtt`,
since this only disables auto inclusion of these modules
This is a temporary solution since this is already possible with
Kconfig, but not in make.
To avoid confusions between `auto_init_ztimer` and `ztimer_auto_init`
rename `ztimer_auto_init` to `ztimer_init`.
This allows for similar handling as `saul_init_devs` and
`auto_init_devs`. Dependencies are therefore done against the USEMODULE
and not DEFAULT_MODULE or checking DISABLE_MODULE. For this, both
`ztimer_init` and `auto_init_ztimer` are added to DEFAULT_MODULE and
both need disabling if the user does not want that module in.
With this, the comment in Kconfig no longer applies.
wire up ZTIMER_SEC to the existing RTC backend, or RTT backend, or periph_timer
backend (in this order of preference).
Update sys/ztimer/auto_init.c
Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
This commit adds logic to make xtimer use ztimer_usec as backend
(instead of periph_timer). This allows ztimer_usec and xtimer to
coexist. It also allows xtimer to profit from eventually implemented
power mode blocking in ztimer's periph_timer backend.
