So my suggested solution is to pull in ztimer_periph_rtt if available, or ztimer_periph_timer otherwise in the case ztimer_msec is used.

The issue with that is that periph_rtt doesn't always allow 1000hz (or higher) . Some only do 1hz. IIUC ztimer will silently fail in that case.

I see, so it seems we need a smarter way to fix this. Would be great if we could fix this once and for all, sucks to have to care about this issue every time ztimer_msec is used...

How about we model some kind of board feature that we can use to select a fitting ztimer backend?

This really is an FAQ by now BTW, about everyone using ztimer runs into this issue ;)

How about we model some kind of board feature that we can use to select a fitting ztimer backend?

That would probably be the best. First step would be to configure all RTT to the same frequency (by default), if possible.
Like, 32768KHz. Maybe some of the offenders are just not configured correctly.
Then we need to figure out if we just bake the current configuration (frequency) into a feature, or the possible ones. And if feature selection reconfigures the RTT.

Its been a while since the last time I had a deep dive into ztimer. But couldn't we select ztimer_periph_rtt and ztimer_periph_timer if ZTIMER_MSEC is used and let auto_init.c select one of them? During compilation RTT_FREQUENCY is known and the pre-processor can select either one. The linker will then throw out the unused ztimer_periph, wouldn't it?

But couldn't we select and ztimer_periph_rtt and ztimer_periph_timer if ZTIMER_MSEC is used and let auto_init.c select one of them?

Unfortunately, this would (at least in the current state) defeat the purpose: that would lead to the inclusion, and initialization, of the periph_timer. And that is exactly what should be prevented for the case that ZTIMER_MSEC is usint periph_rtt as backend...

Unfortunately, this would (at least in the current state) defeat the purpose: that would lead to the inclusion, and initialization, of the periph_timer. And that is exactly what should be prevented for the case that ZTIMER_MSEC is usint periph_rtt as backend...

Isn't the respective periph_timer initialized by ztimer_periph_timer_init()? If the latter on isn't initialized, periph_timer shouldn't be, as well?

The issue with that is that periph_rtt doesn't always allow 1000hz (or higher) . Some only do 1hz. IIUC ztimer will silently fail in that case.

We discussed something similar in #16116. A compatible RTT could be modeled as a feature.

Ah, should have read further, I now saw that you came to the same conclusion :-).

Isn't the respective periph_timer initialized by ztimer_periph_timer_init()? If the latter on isn't initialized, periph_timer shouldn't be, as well?

True. For a short moment I thought it is initialized in periph_common/init.c, but thats not the case - pardon me... Then it seems like the suggested approach could work, will give it a try!

This issue had also been tackled in #14013, but came to the same issues.

I thought for RTT we should have features exposing 1Khz, 32Khz capabilities, maybe more later as needed. So FEATURES_PROVIDED += periph_rtt_1khz FEATURES_PROVIDED += periph_rtt_32khz. In most cases, the underlying clock is 32Khz except for espandatmega. The trouble with the later is that it depends on the actual clock backend, so I think it's easier to model this as capabilities instead of the actual clock speed. So maybe ztimer_rtt_32khandztimer_rtt_1khzare more fitting since it will only mean I can get an1khz or 32khz ztimer_rttfrom myperiph_rtt. And in all cases where RTT_FREQUENCY` is higher than the target frequency, this can be achieved, and if it's lower, it can if the target frequency is power2 of the actual frequency.

But then how to configure it? So far it's compile-time, so conflict between configurations should be caught, for OpenWSN I set the highest possible speed, and for a lot of platforms, I made the RTT_FREQUENCY configurable and add RTT_MAX_FREQUENCY. Is there any reason to not set the max frequency as the default frequency?

So to summarize:

• ztimer_rtt_32kh and ztimer_rtt_1khz features
• set RTT_FREQUENCY to RTT_MAX_FREQUENCY if ztimer_rtt_32kh and ztimer_rtt_1khz are used, with CFLAGS.

In any case it makes a lot of sense to keep this discussion in a single place. anyone objecting to close this PR and continue discussion in #14013?

ok then :-)

closing in favor of #14013