joel.sherrill at OARcorp.com
Wed Nov 8 14:25:13 UTC 2000
"Aaron J. Grier" wrote:
> On Tue, Nov 07, 2000 at 02:30:46PM -0700, "Michael P. Collins" on korat wrote:
> > 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.
> I have a 68331-based system and ran into a similar situation. I ended
> up using the GPT and bypassing RTEMS.
:( See below. Just a clock tick device driver construction issue.
> > 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?
> bsp_start() maybe?
You don't have to circumvent the macros if this is simply an application
configuration. Set the CONFIGURATION_MICROSECONDS_PER_TICK to whatever
you want. The problem is the construction of the clock tick driver.
THe powerpc decrementer based clock tick driver does it better. See
c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c and notice that it
takes a BSP supplied value for an arbitrary clock tick. Basically
you just have to program the tick source based on the value configured.
> Aaron J. Grier | Frye Electronics, Tigard, OR | aaron at frye.com
> "Calling anything from the x86 world a 'masterpiece' seems, to me,
> like putting a gold star on the best-looking fingerpainting in the
> special-needs Kindergarten class." -- Wakko Warner
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
More information about the users