drivers/{at24cxxx, at25xxx}: move to ztimer

[fabian18]

Contribution description

Move to ztimer for at24cxxx and at25xxx

Testing procedure

Issues/PRs references

[crasbe]

Since the AT24CXXX_POLL_DELAY_US and POLL_DELAY_US are 1000us = 1ms, it would probably be better to use ztimer_msec since the microsecond timer of ztimer adds a significant power efficiency penalty.

[riot-ci]

Murdock results

✔️ PASSED

59e7a8a drivers/at25xxx: move to ztimer

Success	Failures	Total	Runtime
10535	0	10536	19m:53s

Artifacts

• Documentation preview

[crasbe]

You'll have to add #include <inttypes.h> for PRIu8 and #include "architecture.h" for PRIuSIZE.
Apparently this was previously included implicitly by xtimer.h and not anymore by ztimer.h.

This is not your fault though.

[fabian18]

better to use ztimer_msec

not sure, usually you must be prepared to be off by +- 1 timer tick

[crasbe]

better to use ztimer_msec

not sure, usually you must be prepared to be off by +- 1 timer tick

Unfortunately I can't give a qualified answer to that. I'll poke Martine to have a look at it :)

[crasbe]

I poked Martine today (twice even) and another experienced RIOT dev, but there is not a clear answer. The underlying "tick" depends on the frequency of the timer that is used for the ZTIMER_MSEC. In many cases this is the RTT, but it can have different frequencies. Sometimes it's 1024Hz and sometimes it's 32768Hz. In the former case, waiting for 1ms might result in (close to) 2ms wait time, but never 0ms.
In the latter case the wait time should be 1ms+-30µs if I understood it correctly.

Considering this is just a delay for polling, I still don't think it's worth using the ZTIMER_USEC and it would probably be acceptable if the delay is between 1-2ms and it shouldn't have a performance penalty either if I understood the code correctly.

[benpicco]

ZTIMER_MSEC might not always be available.
But you can use xtimer_msleep() which will always select an appropriate backend.