Periodic timer?

Aaron J. Grier aaron at
Wed Aug 22 18:45:01 UTC 2007

On Tue, Aug 21, 2007 at 07:57:25PM -0400, Robert S. Grimes wrote:
> What is the preferred way to implement a periodic timer?  My first
> attempt was to use an rtems_timer, calling rtems_timer_fire_after, but
> this only fires once, and I couldn't find an option to cause it to
> repeat automatically.

you can have the timer function set itself to fire again.  (:

> I ended up using rtems_rate_monotonic_period instead, even though I
> don't care about missing a deadline here.  Still, it seems kind of
> cool to know when I do miss a deadline!  So, here is my approach,
> simplified:
>     // Use rate monotonic periods
>     while (1) {
>        status = rtems_rate_monotonic_period(period, perTicks);
>        doWork();
>        if (status != RTEMS_SUCCESSFUL) {
>           reportError("Too slow!");
>        }
>     }
> Question 1: Is this an appropriate (mis)use of
> rtems_rate_monotonic_period?

that's standard usage.

> Question 2: Let's assume doWork() normally takes perhaps 50% of the
> period to execute.  What happens if doWork() it takes too long every
> now and then?  Is the timing of subsequent periods maintained, or is
> it reestablished the next time through the loop?  I'm guessing the
> latter.

I believe a call to rtems_rate_monotonic_period() re-establishes the
beginning of another period, even if the previous period's deadline has
expired.  Joel?

> Question 3: Given my assertion that I don't care too much about late
> deadlines here, is it an overkill compared to this approach?
>     // Simple sleep
>     while (1) {
>        rtems_task_wake_after(perTicks);
>        doWork();
>     }

the benefit of using rtems_rate_monotonic_period() is that the time of
doWork() is included in the period.  with the simple sleep(), the
periodicity will be sleep + doWork.

  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at

More information about the users mailing list