MPC5200 RTEMS Tick

[Pavel Pisa]

Hello Simon and Joel,

On Thursday 25 January 2007 19:08, Joel Sherrill wrote:
> > 2)       On the other hand, if RTEMS is servicing ticks at 10ms and I
> > use an available timer to give me interrupts every 1ms to run an ISR.
> > How does this periodic interrupt affect task execution since RTEMS
> > needs to manage this interrupt?
>
> With approach one you get 10 ISRs per 10 milliseconds.  With approach
> two, you get 11.  So that is a factor in your decision.
>
> You might be able to process each ISR in a "light" manner and every few
> ISRs do more processing.  It depends on the application.
> For example, you might just sample something in the 1 millisecond ISR
> and every 10 milliseconds process them.

I would like to add only, that you should not have any
problems due load caused by RTEMS executive overhead for
1 ms period on so powerfull hardware as MPC5200 is.

We have used setup similar to your 2) on much much
weaker HW successfully. We have tested porting of our eight
axes system-less motion control software to the RTEMS
as topic of one diploma thesis[1].

We have used 1 ms system tick (CONFIGURE_MICROSECONDS_PER_TICK 1000),
the task timed by RTEMS timers for period durations 250 ms, 8 ms
and 10 ms. The precise timing of motion control task has been
realized by running code in high priority thread which has been
released by rtems_event_send() from separated timer interrupt
configured for 1 ms as well. This task runs for each axis position
control loop and trajectory generator or one central trajectory
generator for interpreting polynomial coefficients parameterized
movements (for spline trajectories). All code has been highly
optimized to do all computation in fixed point formats.

All this has run on our MO_CPU2 based on MC68376 running at 21 MHz.

So your requirements would generate probably neglectable load
caused by RTEMS executive code.

RTEMS rocks :-)

> It all depends on what you are trying to do every millisecond.  If it
> takes you 250 microseconds to process it, then 25% of
> your CPU is dedicated to that.  BIG MULTIPLIER on CPU load so design is
> critical.

ACK, the application code could simply cause system overload.

Best wishes

             Pavel Pisa

[1] The diploma thesis
    MOTION CONTROL SYSTEM FOR MANIPULATORS AND ROBOTS
    by Jakub Stola
http://dce.felk.cvut.cz/dolezilkova/diplomky/2006/bp_2006_stola_jakub/eng/
full text - unfortunately Czech only 
http://dce.felk.cvut.cz/dolezilkova/diplomky/2006/bp_2006_stola_jakub/BP_2006_STOLA_JAKUB.pdf