ISR to task scheduling help

[Aaron J. Grier]

I'm in the process of trying to convert what used to be an ISR into a
task, but having a heck of a time.

the task is a hardware handler -- it needs to wake up, check to see if
there's any work to do and do it, and if not, go back to sleep.

my initial thought was to make it a high priority task with
(RTEMS_NO_TIMESLICE | RTEMS_NO_PREEMPT), and then use
rtems_rate_monotonic_period(period_id, 1); to get it to run on every
tick, but the delay between clock tick and return from
rtems_rate_monotonic_period varies more than I would like.

here's a distribution of timing from the clock tick handler, which
subsequently calls rtems_clock_tick().  each of the bins is 1/256th of a
clock tick.  (it's my sampling clock.):

{0 <repeats 147 times>, 1, 0 <repeats 69 times>, 2, 2142,
  0 <repeats 37 times>}

here's the distribution I see in the task:

{0 <repeats 60 times>, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
  0 <repeats 151 times>, 96, 0, 2026, 0 <repeats 21 times>, 15, 2, 1, 0,
  0, 0, 0, 0, 0}

aside from a tick of startup noise, the clock tick is tightly clustered
around bin 218, and I would expect to see similar distribution in my
task, but it's smeared.

am I misunderstanding how the rate monotonic manager works?  is there a
way to get more consistent timing?

I'm going to try using RTEMS timers next.  it looks like they get run
before any of the task scheduling, and I might be able to eliminate the
"work to do" check (since the timer will never be fired if there isn't
any work to do) and I'm hoping I can get more consistent timing.  just
figured I'd check in here to make sure I'm still sane and on the right
track.

thanks.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com