Default RTT_frequency

In #16116 some thoughts where shared about RTT_FREQUENCY.

maybe a sensible default should be choosen.

there are two mainly used ~32kHz and 1Hz (non 1000Hz)

grep “define.*RTT_FREQUENCY” showed

32k     19
1       12
Max     3 (iotlab is one)  at a first glace these are 32kibiHz
16k     3
1024    2
4096    1 (nucleo-f413zh)

there are 5 rtt users in sys/Makefile.dep

ztimer       (likes to put msec on rtt)
posix_sleep  ztimer_msec
gomach (somthing about 300ms supercycles)
lwmac  (calculates in 2ms - 300ms range)
sklad  ztimer_msec

since not every RTT is configurable a sane default should be choosen i vote for ~32kHz

1 Like


The available frequencies could maybe be modeled as features. At least 32kHz, 1024kHz and 1hz. That way we can maybe make ztimer only depend on RTT if it provides a usable frequency.

11 of the 1 Hz ones are efm32* i had a short read on a datasheet of that series and i support other perscalers the current implementation is not able to be configured by setting RTT_FREQUENCY maybe @basilfx is able to change that or get the default to something faster (i got no efm32 device and therefor can not test)

the other one is the arduino-due a sam3 which reads the RTT_FREQUENCY define for configuration

They should be configurable:

1 Like

Yes it is available in the hardware library but for Riot it is set to a fixed value cmuClkDiv_32768.

Most mcu take the RTT_FREQUENCY define and use it to configure the RTT. atmega for comarison uses a function to calculate the prescaler, stm32 (but f1) has a list of prescaler defines, sam used a preprocessor function to calculate the value somehow)

I think this can be changed to work similar for efm32.

I don’t think i should write such an PR without being able to test.

The capability for configuration the way other mcu do that is added with