RTEMS4.7 PPC clock API (was Re: IRQ latency )
feng1 at bnl.gov
Mon Aug 15 15:15:25 UTC 2005
Peter Dufault wrote:
> On Aug 15, 2005, at 9:17 AM, Kate Feng wrote:
> > Peter Dufault wrote:
> >> I use the 64-bit Power-PC time counter, not the system clock, so
> >> the timings should be very accurate.
> > It sounds like a good idea to use PowerPC TBL and TBU as
> > a default system clock instead of using the decrementer
> > since it reloads itself.
> >> In an earlier posting I said that if something resets that time
> >> counter I'm in trouble, but I'm 99.99% sure that the time counter
> >> is left alone.
> >> Till will tell.
> > Can the decrementer interrupt be disabled for RTEMS4.7 for
> > thoses PPCs with 64 bit timer since the time counter
> > is ideal to be used as a system clock ?
> Can it interrupt? I thought it just rolled over. I don't think it
> has a reload register, and the 64 bit counter is too slow for most
> uses. I know we have some NASA people, maybe they can use it as the
> clock tick on one of the deep space probes.
> Also, having a free-running 64 bit low overhead (to read back)
> counter is great for timing analysis and data time stamping, and I'd
> be upset if RTEMS started to reload it for its own reasons.
Yes, you are right. Actually rtems_bsp_delay() used it too, not to
but to delay microseconds from present time.
> haven't looked too closely at what's on the MVME5500 but there must
> be a more appropriate clock (one that can both interrupt and has a
> hardware reload value). I'll check later today.
Yes, there are eight 32 bit counters/timers on boards, which reload
and interrupt. However, this will break the API. Perhaps,
it's still good to use the decrementer as a system clock.
> > Regards,
> > Kate
More information about the users