Timed routines

[joel.sherrill at OARcorp.com (Joel Sherrill)]

Eric Norum wrote:
> 
> Joel Sherrill wrote:
> 
> >
> > Now that some time has passed and I don't remember what I said, let's
> > start again.  You can't completely eliminate the need to run the
> > chain of subroutines at each clock time.  That mechanism is used
> > internally
> > by RTEMS for timeouts, etc.  But this is OK because RTEMS handlers are
> > very small.  The TSR support just opened this up to user routines.
> >
> > The current TSR support is good for small things and when used in
> > moderation.
> > But the other approach is better for more general, higher functionality
> > things.
> >
> 
> I agree.  That's why I proposed making the change to
> _Watchdog_Tickle_ticks
> and not to rtems_clock_tick.

If you go this route, then you don't have to change anything in the 
watchdog handler.  The code can be a user of the watchdog and simply
register a routine to fire at the appropriate times.  When there is
nothing to do, it does not have to be on the watchdog chain.

> > Is it possible to support both?  All (I think) it would take is either
> > (1) a
> > new timer manager routine to create a "task level" TSR or (2) a
> > modification
> > to the API of the current timer_create to add an attribute that
> > specifies
> > task level or clock tick level.
> 
> (2) sounds good to me.  When would the decision be made?  At
> rtems_timer_create()
> or at rtems_time_fire..()?  As far as I can tell, either call would have
> to be
> expanded to have another argument -- which implies that (1) may be
> necessary to
> maintain compatability with existing application code.

We invented the timer manager.  Personally, I do not have a problem with
adding a parameter to timer_create.  

> > Eric .. rather than a count and events, isn't it more natural to use a
> > counting
> > semaphore?  This may lead into putting together the "light semaphore" we
> > have
> > talked about periodically as a side-effect.
> >
> 
> I suggested the count/event because I thought it would impose less
> overhead.
> A lightweight counting semaphore would probably be a better way to go.

I think it is more natural and would encourage a simple wrapper around
the
core semaphore.  This would give us an early test case.

> An `immediate action item' should be to add a note in the documentation
> that timer
> callbacks may run in the context of the clock interrupt handler and thus
> be
> subject to all the limitations on calls that can be made from an
> interrupt
> context.

I will see what is there and add to it.

> --
> Eric Norum                                 eric at cls.usask.ca
> Canadian Light Source                      Phone: (306) 966-6308
> University of Saskatchewan                 FAX:   (306) 966-6058
> Saskatoon, Canada.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985