[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 05 Oct 1999 11:17:56 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: Timed routines
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
> 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
> 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
> 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
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
> subject to all the limitations on calls that can be made from an
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