[ECOS] Periodic execution of code in a thread context

Gary Thomas gary@mlbassoc.com
Wed Sep 23 16:07:00 GMT 2009

On 09/23/2009 08:59 AM, Steven Clugston wrote:
> Hi all
> I need to have a function with some control code in it to execute at regular and consistent intervals.
> The way I've done this is just to create a thread and trap the execution path in an infinite loop using while(1){some code;cyg_thread_delay()} or for(;;){some code; cyg_thread_delay()}.
> The trouble with this approach is that if the code doesn't take the same path every time, then the overall interval will vary and the drift will be cumulative. This hasn't mattered too much until now, but I need it to not drift for my current application. I guess it could be improved by using cyg_real_time_clock() at the start and end of the code section to find how long it took then modify the delay time to try to keep the time interval at which the code is started the same, but it seems a bit clumsy and might suffer from jitter which would still be cumulative.
> The other way I've tried is to use a timer/alarm attached to the system clock, but this executes in a DSR context which causes some limitations and I would prefer to use a normal thread context.
> Could I use a cyg_thread_suspend() at the end of each iteration then re-wake the thread from an alarm handler?
> Is there anything which I've missed like a scheduler policy or API call which might help?
> Do I need to resort to a hardware timer to achieve this goal?

One way to handle this is to use select() with a timeout which
is set to a relative time value (computed by checking the current
time relative to a known value).  Hence your loop looks something
like this:

    gettimeofday(&base_time, NULL);
    while (1) {
      ... do some work
      // Calculate when to resume
      timeradd(&base_time, &time_per_loop, &base_time);
      // And how long that is from now
      gettimeofday(&now, NULL);
      timersub(&base_time, &now, &delta);
      // Wait for that much time

Of course this solution, like the others that have been posted,
is only accurate to the system timer/tick.  If you need higher
resolution than that, you'll need a separate hardware timer.

Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list