Robert S. Grimes
rsg at alum.mit.edu
Wed Aug 22 19:05:00 UTC 2007
Aaron J. Grier wrote:
> 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. (:
True, but not terribly elegant ;)
>> Question 1: Is this an appropriate (mis)use of rtems_rate_monotonic_period?
> that's standard usage.
Exactly the answer I needed - and hoped for.
>> 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
> 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?
That's my guess. The answer doesn't really matter to me, but knowing it
does - I need to document the behavior. Low priority right now...
> 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.
Of course, that is my source of my concern to begin with! Be that as it
may, your "that's standard usage" means I've resolved how to handle this
issue - use rtems_rate_monotonic_period(). That works just fine for me.
Thanks, Aaron, for filling in the missing brain context on my part!
More information about the users