Note that ztimer is not supported on every RTT. E.g. when the RTT frequency is 1 Hz, users setting millisecond timeouts will be quite surprised about the lack of accuracy.

Searching for RTT_FREQUENCY reveals quite a few instances of a 1 Hz RTT clock:

boards/common/arduino-due/include/periph_conf.h
79:#define RTT_FREQUENCY       (1U)        /* 1Hz *

boards/ikea-tradfri/include/periph_conf.h
86:#define RTT_FREQUENCY       (1U)

boards/stk3200/include/periph_conf.h
104:#define RTT_FREQUENCY       (1U)

boards/e180-zg120b-tb/include/periph_conf.h
88:#define RTT_FREQUENCY       (1U)

boards/slstk3401a/include/periph_conf.h
117:#define RTT_FREQUENCY       (1U)

cpu/kinetis/include/periph_cpu.h
167:#define RTT_FREQUENCY                (1)

... and many more

Note that ztimer is not supported on every RTT. E.g. when the RTT frequency is 1 Hz, users setting millisecond timeouts will be quite surprised about the lack of accuracy.

Then it seems to me that having periph_rtt is not sufficient to use the RTT backend, right? Should we then have something like HAVE_ZTIMER_COMPATIBLE_RTT?

Then it seems to me that having periph_rtt is not sufficient to use the RTT backend, right? Should we then have something like HAVE_ZTIMER_COMPATIBLE_RTT?

That would be awesome!

i had a short look into the arduino-due manual and saw that the rtt of its MCU capable of running at higher frequencys (just depends on the Prescaler which is independent for rtc(always 32....kHz and rtt (selectable)).
I think this might be the same for many of the incompatible Boards.

i had a short look into the arduino-due manual and saw that the rtt of its MCU capable of running at higher frequencys (just depends on the Prescaler which is independent for rtc(always 32....kHz and rtt (selectable)).
I think this might be the same for many of the incompatible Boards.

So, if this would be made configurable, could we do something like the following?

config PRESCALER
    int "Prescaler"

config HAVE_ZTIMER_COMPATIBLE_RTT
    bool
    default y if PRESCALER > SOME_VALUE

With the new structure for the ztimer peripheral selection process in #15715 a automated decision in the compilation process would be simple to implement.

why not have a ztimer_rtt if there is a rtt but just not use it for ms if it has not enaugh resolution

sec use rtt if rtt_freq>= 1

ms use rtt if rtt_freq>= 1000

why not have a ztimer_rtt if there is a rtt but just not use it for ms if it has not enaugh resolution

sec use rtt if rtt_freq>= 1

ms use rtt if rtt_freq>= 1000

Currently there is no information in Kconfig about the RTT frequency. If that information is added then the dependencies of the ms can be changed to add the frequency constraint.

for the atmega it is done like this ( seems very intransparent)

static inline uint8_t _rtt_div(uint16_t freq)
{
    switch (freq) {
    case 32768: return 0x1;
    case  4096: return 0x2;
    case  1024: return 0x3;
    case   512: return 0x4;
    case   256: return 0x5;
    case   128: return 0x6;
    case    32: return 0x7;
    default   : assert(0);
                return 0;
    }
}
rtt_init(void){
...

    /* 32768Hz / n */
    TCCR2B = _rtt_div(RTT_FREQUENCY);
   ...
}

does kconfig support lists of options?

does kconfig support lists of options?

It supports choices. As an example see the clock configuration for STM32 https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32/kconfigs/Kconfig.clk

For reference: https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html

It is also a pity that there is no API for querying the supported frequencies for a given RTT. A one size fits all RTT_FREQUENCY define is just not sufficient IMO.

Maybe we could also drop the RTT API altogether and just use periph_timer for all non RTC (with C = clock, not c = counter) timers.

Should I then, for now, swap the preference in the defaults for this PR?

Should I then, for now, swap the preference in the defaults for this PR?

That would be nice. But there might still be boards that actually cannot set their RTT to 1kHz / 1.024 kHz - I have no idea. If all boards support 1 kHz / 1.024 kHz, using this by default would be awesome for ztimer.

Changed the default backend and updated the description accordingly.

If @maribu or @kfessel have any reason to disagree, now is the time.

I'm fine, go ahead!

Should I then, for now, swap the preference in the defaults for this PR?

That would be nice. But there might still be boards that actually cannot set their RTT to 1kHz / 1.024 kHz - I have no idea. If all boards support 1 kHz / 1.024 kHz, using this by default would be awesome for ztimer.

atm most boards that define some RTT_frequency seem not to be set to ~1kHz they are either (much) higher (~32kHz most) or 1Hz

32k     19
1       12
Max     3 (iotlab is one)
16k     3
1024    2
4096    1 (nucleo-f413zh)

atm most boards that define some RTT_frequency seem not to be set to ~1kHz they are either (much) higher (~32kHz most) or 1Hz

I will take that as a future PR will be needed!

atm most boards that define some RTT_frequency seem not to be set to ~1kHz they are either (much) higher (~32kHz most) or 1Hz

I will take that as a future PR will be needed!

you are right i just thought about that when i read it here and did some counting