RIOT-OS
drivers/{at24cxxx, at25xxx}: move to ztimer
Contribution description
Move to ztimer for at24cxxx and at25xxx
Testing procedure
Issues/PRs references
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.
Murdock results
:heavy_check_mark: PASSED
59e7a8a48b3faab2924c757a840da74a64b25ab1 drivers/at25xxx: move to ztimer
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 10535 | 0 | 10536 | 19m:53s |
Artifacts
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.
better to use ztimer_msec
not sure, usually you must be prepared to be off by +- 1 timer tick
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 :)
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.
ZTIMER_MSEC might not always be available.
But you can use xtimer_msleep() which will always select an appropriate backend.
