MPC5200 RTEMS Tick

[Joel Sherrill]

Simon Yuen wrote:
> Thank you for your reply.
>
> What do I need to do to support this timing idea using RTEMS... set
> Timer0 or Timer1, whichever RTEMS uses, to interrupt every 1ms to run
> the ISR.  Then for every 10ms interrupt, report back to RTEMS using the
> rtems_clock_tick directive.  What needs to be done to use RTEMS
> interrupt management and take advantage of RTEMS features?
>
>
>
>   
The BSP should be setup to automatically program whichever timer is being
used for the clock tick based upon the configuration table entry for 
microseconds
per tick.

So that leaves you with an unused timer which most likely leaves you to 
program
and establish an interrupt handler for.  The clock tick driver should be 
a good model
on how to hook up the ISR.  If the timers are similar in programming 
model, then
it may just be mostly a matter of careful cut, paste, and substitute the 
timer number.

--joel
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
> Sent: Thursday, January 25, 2007 10:09 AM
> To: Simon Yuen
> Cc: rtems-users at rtems.org
> Subject: Re: MPC5200 RTEMS Tick
>
> Simon Yuen wrote:
>   
>> I am a newbie to RTEMS and the MPC5200.   My project requires a timely
>>     
>
>   
>> periodic task to run every 1ms but I am not sure how to approach 
>> this.  Here are a few questions I hope someone can shed some light on.
>>
>>  
>>
>> 1)       If I set CONFIGURE_MICROSECONDS_PER_TICK to give me a 1ms 
>> tick, how much overhead would this cause to program execution running 
>> two tasks?  I like to use the rate monotonic manager to run a task 
>> every 1ms.
>>
>>  
>>
>> 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?
>>
>>  
>>
>> 3)       Which is the better approach?
>>
>>     
> Approach 1 will probably work fine on a reasonably fast CPU.  With 
> either approach, you have to account for the CPU time
> used by getting an interrupt every millisecond, context switching to 
> that task, and doing whatever it is you want to do.
>
> Be careful because processing something at this rate can easily be a 
> large percentage of the CPU load.
>
> 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.
>
> 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.
>   
>>  
>>
>>  
>>
>>  
>>
>> Thank you
>>
>>  
>>
>>  
>>
>> Simon
>>
>>
>>     
> ------------------------------------------------------------------------
>   
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>>     
>
>