The sam0 rtt busy loops for 180us every time an alarm is set or
the counter is read, this propagates and leads to timing errors
on ztimer_msec that are higher than > +-1msec.
The same goes for fe310.
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.
ztimer's machinery depends on figuring out if a timer is currently set
or not. It does that using _is_set(), which is also exposed as
ztimer_is_set().
Now when a timer expired and got taken of the timer queue using
_now_next(), the `next` pointer wasn't unset. This caused _is_set() to
wrongly return `true` for that timer.
Internally in ztimer, this didn't cause breakage, just an unnecessary
iteration of the timer queue by _delete_timer_from_list().
But this also broke the public ztimer_is_set().
This commit fixes the issue by correctly NULLing the timer's `next`
pointer when the timer triggers.
MSEC and SEC are now usable on TIMER(0) without having USEC
pm is configured by used hardware
OLD configuration values are translated for backward compatibility
prefer rtt for ZTIMER_SEC
avoid doing partial ztimer setup if auto_init_ztimer is disabled
before this patch some const pointers might have been definend to values
that a user who disables auto_init for ztimer does not like.
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>
