Re: Drift through k_sleep or k_msleep #api


Michael Rosen
 

Nick,

 

The design pattern Ive seen for this kind of thing uses the Timer API instead of sleep:

 

struct k_timer timer;

k_timer_init(&timer, NULL, NULL);

k_timer_start(&timer, 0, K_MSEC(1000));

while (1) {

  k_timer_status_sync(&timer);

  …

}

 

This lets the body of the main loop run only when the timer expires, and the periodic timer avoid drift from resetting the timer at the top of each loop.

 

Mike

 

From: users@... <users@...> On Behalf Of Erik Englund
Sent: Wednesday, February 3, 2021 2:38 PM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: users@...
Subject: Re: [Zephyr-users] Drift through k_sleep or k_msleep #api

 

One possible solution is to create a periodic timer and post to a semaphore in the timer callback.

A thread could simply wait on the semaphore in an endless loop.

 

Linux clock_nanosleep (mostly used togheter with Preempt-rt patch) would be a nice addition to Zephyr, that would solve these kinds of tasks.


Med vänlig hälsning

Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA


Org.nr. 556790-2977
www.innoware.se

 

 

Den ons 3 feb. 2021 kl 20:31 skrev Nikolaus Huber <nikolaus.huber@...>:

Hi all, 

I was recently wondering about the correct usage of k_sleep or k_msleep for implementing periodic tasks. In FreeRTOS for example there is a function vTaskDelayUntil which takes a timestamp and a number of ticks to delay. By taking the timestamp at the beginning of the execution of a task we can then make sure that its release time does not slowly drift. So far I have not seen anything similar in Zephyr. Am I missing something, or do I have to somehow create a similar mechanism on my own by measuring the uptime at the release of a periodic task and then again just before using any sleep function to calculate the exact sleep time I want?

Thank you very much in advance,
Nick

Join users@lists.zephyrproject.org to automatically receive all group messages.