tick timing

[mcollins at hawkeye.sps.mot.com]

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