[riot-notifications] [RIOT-OS/RIOT] sys/ztimer: initial import (#11874)

Kaspar Schleiser notifications at github.com
Tue Sep 10 10:57:53 CEST 2019


kaspar030 commented on this pull request.



> + *
+ * @c last_wakeup should be set to ztimer_now(@p ztimer) before first call of the
+ * function.
+ *
+ * If the time (@p last_wakeup + @p period) has already passed, the function
+ * sets @p last_wakeup to @p last_wakeup + @p period and returns immediately.
+ *
+ * @param[in]   ztimer          ztimer clock to operate on
+ * @param[in]   last_wakeup     base time stamp for the wakeup
+ * @param[in]   period          time in ticks that will be added to @p last_wakeup
+ */
+void ztimer_periodic_wakeup(ztimer_dev_t *ztimer, uint32_t *last_wakeup,
+                            uint32_t period);
+
+/**
+ * @brief   Put the calling thread to sleep for the specified number of ticks

> Does this sleep at least `ticks` or at most `ticks`.

Well, the implementation sleeps "at least x ticks". I guess this information has to be added everywhere.

> As far as I know, RIOT never had the goal to provide **hard** real time features, but **soft** real time features instead.

I think that is what the website states. Actually, it is more complicated. Parts of RIOT are fully hard real-time capable, some parts are not, some parts are only if certain constraints are honored. With care, it is perfectly possible to do hard real time with RIOT. **but**, you really have to know the internals, as documentation on the matter is severley lacking.
Still, I like that doing hard real-time with RIOT is possible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11874#discussion_r322626854
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190910/44afe832/attachment.htm>


More information about the notifications mailing list