tick timing

[Joel Sherrill]

Many of the older BSPs, set things up to get an interrupt a millisecond
and count milliseconds between calls to rtems_clock_tick().  Check the
clock tick code and it will be obvious.  See this from the ISR:

  Clock_driver_ticks += 1;

  if ( Clock_isrs == 1 ) {
    rtems_clock_tick();
    Clock_isrs = BSP_Configuration.microseconds_per_tick / 1000;
  }
  else
    Clock_isrs -= 1;


The timer is probably programmed correctly to do 1 tick per configured
"microseconds_per_tick" and now each tick ISR should call
rtems_clock_tick().
Just be sure that if someone configures a value too large, that you
do something reasonable.

" (Michael P. Collins on korat)" wrote:
> 
>   I set out to make some changes to my BSP (which is derived from efi332)
> yesterday, and ran into a snag that took a while to untangle.  One of
> my changes involved the tick timer.  This is a hardware timer derived
> from the 32.768kHz crystal oscillator, and in efi332 was set to 36
> clock periods.  I determined from system timing analysis (my BSP runs with
> a system clock of ~25.2MHz) that my BSP should work with a tick interval
> of 4 system clocks, or about 122us.  When I updated my clock initialization
> routine and the parameters used by "confdefs.h", however, my RTC quit
> working.  Further investigation revealed that the interrupt period is
> as expected, and there is sufficient bandwidth to handle the higher
> tick rate, but the problem lies with the MICROSECONDS_PER_TICK
> value.  If I re-compile my application using the old value of 1089,
> the TOD clock runs 9 times too fast, but any value < 1000 won't work at
> all.  Although I haven't tracked this down completely, it would appear
> that the significance of 1000 is related to integer division in the
> macros.
> 
>   I haven't found any recommendation in the documentation I've read
> regarding tick intervals, but it would appear that they are limited
> (to at least some extent) to 1ms or more.  This seems a bit long given
> the potential speed of modern hardware.  I was initially looking for
> a simple way to implement a reliable delay routine, and it looked like
> I could get away with an rtems_task_wake_after() call, but I need
> better resolution than a millisecond.  Can I circumvent the macros
> in "confdefs.h" and directly assign a value of 122 to
> BSP_Configuration.microseconds_per_tick?  If so, how would I best go
> about doing this?
> 
>                                         -- MC --

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