Replies: 2 comments 1 reply
-
CC @andyross |
Beta Was this translation helpful? Give feedback.
1 reply
-
Yes, k_sleep() and variants will internally round up to the next tick boundary after the desired expiration and are guaranteed to sleep at least that long (or to return a non-zero result if they couldn't). Though be aware getting reliable intervals with this kind of code is dangerous even with that promise. Look at absolute timeouts, sys_timepoint, and k_timer's periodic interrupt facility for a better choice. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I understand they can be interrupted and will return the remaining time to sleep, but the question is if they aren't interrupted via k_wakeup(), will k_msleep(1), or k_msleep(5) etc sleep for at least 1ms and at least 5ms?
Ran into an issue with FreeRTOS vTaskDelay() where there is no guarantee that the sleep ticks is a full tick, so you can sleep for 5 ticks via vTaskDelay(5) and end up sleeping for only ~4 ticks. This is a significant limitation and wanted to understand if Zephyr was in the same spot or if there were techniques used by the OS to provide a "sleep for at least X" promise.
The documentation doesn't indicate one way or the other afaict.
Beta Was this translation helpful? Give feedback.
All reactions