drivers/periph_common: problems with starting RTC early

[ZetaR60]

In #8842 I have had trouble with race conditions when using xtimer. This is solved by removing rtc_init from drivers/periph_common/init.c and moving it to the application (tests/periph_rtc). It seems that code in drivers/periph_common/init.c is executed before xtimer_init, which is in sys/auto_init/auto_init.c

Steps to reproduce: use xtimer_usleep in rtc_init

Expected results: xtimer functions normally

Actual results: xtimer hangs the system prior to kernel_init

Versions:

• avr-gcc: avr-gcc (Fedora 7.2.0-1.fc27) 7.2.0
• avr-libc: "2.0.0" ("20150208")
• git: git version 2.14.2

[jnohlgard]

I think this would benefit from a more dynamic approach to auto_init, which could be possible using xfa (under development in #7523). That said, I think your rtc driver design is flawed if you need xtimer for controlling the on CPU RTC. The periph drivers are the lowest level interface drivers toward the hardware, all other drivers depend on them for hardware interfaces, therefore it makes sense to initialize them first. Why do you need xtimer in your rtc driver?

[ZetaR60]

Strictly speaking, it does not require xtimer. On the ATmega, safe access to several registers controlling the asynchronous timer is not guaranteed. There is a register that has busy flags that you have to wait on before you can safely write them (and for one register, even reading it requires waiting on a flag). This wait can be up to two cycles of the RTC timer, each of which is around 30ms. xtimer is useful because it allows the system to be doing other things rather than just spinning while waiting.

I think it is odd that the RTC is initialized where it is, while other low-level drivers (such as the RTT) are not automatically initialized anywhere except in code for specific boards. I propose that the RTC should be considered similarly to how the RTT is handled: if a specific board or cpu needs it initialized very early, it can be added to the code specific to that board or cpu.

[jnohlgard]

We are working towards moving the periph initialization to periph_init which is called from the board init. This reduces the amount of code that has to be maintained for each individual board.

[ZetaR60]

Should I just make the system spin while waiting on those flags? Even thread_yield won't really be useful because periph_init is called before kernel_init.

[jnohlgard]

Let's continue this discussion in the proper PR

[ZetaR60]

Closing. I asked my question in #8842.