-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/ztimer_usleep: add sleep test for ztimer #14931
Conversation
I can reproduce these numbers for nrf52840dk. Don't have the airfy beacon to cross-check. There's indeed a knob that's not configured: each ztimer clock has a value that's subtracted from every timer that's set.
Setting this reduces the xtimer_usleep error by 7, as expected. Still there are 20-23us left in the sleep test. (We cannot set that adjust value higher, as it would then lead to timers triggering earlier than set). I then tried to measure the time it takes from the ztimer isr to right after waking up. I tried figuring out if the NRF's flash cache has any impact. Enabling its profiling shows 100 cache misses from before to after the sleep(). Disabling the i-cache completely shows 212 cache misses, and increases the overhead by ~1us. So I'd assume we're not a victim of flash cache misses. So for now:
|
Awesome, thanks for the analysis! The
Lastly for comparison the last run of
So same conclusions here:
One more question: does |
To get a better overview, here are the same logs for the
Looking at these numbers, it does not seem this is a |
Here's a way to adjust for the offset: #14936 |
By request from @kaspar030 I've hooked up my logic analyzer to the nrf52840dk and measured some functions using dbgpin. See bergzand@6fe5eac for the spots where I added the dbgpin calls. The logic analyzer is sampling at 16 MHz here: And the raw data as "srzip session file format data" and zipped so that github doesn't complain (supported by pulseview): |
On the cortex-m0+ this picture is going to look a bit different. First it doesn't support the no_idle_thread feature, so instead of one long |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Contribution description
When trying to get #14897 running on a slower board (
arify-beacon
-> nrf51 @ 16MHz) I stumbled upon the behavior already described in #10073:xtimer
experiences a constant offset when setting it, in my case81µs +- 2µs
. I obtained this value using logic analyzer with the driver code from #14897, but I get the same value runningtests/xtimer_usleep
. My hope was to mitigate this problem by simply usingztimer
, but here I run into the same problem...To raise awareness for this, I think it is a good idea to apply the
xtimer_usleep
PR toztimer
. So this PR more or less copies the existingxtimer
test and simply usesztimer
instead. To also get a feeling on the overhead in conjunction with spinning, I added some shorter sleep values as well.From my two quick tests I got the following offsets:
airfy-beacon
(Cortex-M0, 16MHz):nrf52840dk
(Cortex-M4f, 64MHz):IMO these would be ok for very coarse timings, but for any timeout > 100µs there should not be such kind of imprecision, right?!
Or did I miss something in terms of configuration options etc, that would allow to compensate for this offset?
Testing procedure
Run with any boards at your disposal, you should see the same output as running
tests/xtimer_usleep
- the same except the offset values that should be slightly different forztimer
.Issues/PRs references
show cases that #10073 also holds for
ztimer