Re: Drift through k_sleep or k_msleep #api


Erik Englund
 

I guess the internals of this uses a semaphore aswell to get realtime performance.

If you control the semaphore yourself as per my example, you can check the status of the semaphore in the end of the function to see if the timer has expired while the work was running, if so, you have a realtime problem.
We use this technique in Zephyr within a few PLC-type controller products, using 1000 ticks/second rate and cycletime of 10ms.

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 21:10 skrev Michael Rosen <michael.r.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.