RTEMS4.7 PPC clock API (was Re: IRQ latency )

[Kate Feng]

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
reload,
but to delay microseconds from present time.

> I
> 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.


Thanks,
Kate

>
>
> Peter
>
> >
> > Regards,
> > Kate
> >
> >
> >
> >