[uClinux-dev] realtime scheduling...

Lars Segerlund lars.segerlund at comsys.se
Fri Mar 14 02:15:45 EST 2003


  Well I haven't measured 'exactly' yet, but it's the time for the 
interrupt to occur, ( 4 words on stack, + some cycles ), but it's 
constant since I'm running in the internal SRAM of the coldfire ( got 
some macros and a set of code to copy stuff in there ).

  My best current guess is about 6-8 clock ticks, however i do 
compensate for this which means that I can hit the 15 ns ( +-7 ns ) 
window for a
desired instruction to occur in.

  In other words, it's the same as coding an interrupt on the raw 
hardware, this way of scheduling doesn't incur any overhead at all in 
this respect.

  I got a call along the lines :

  sch_reg( *func(), type, ... , off )

  where off is the number of cycles to 'preschedule' on. This works 
since i schedule them in batches, with a call like :

  sch_sch( batch )

  where batch in an integer telling how many of the 'registered' 
interrupts to schedule, 8 or all if ZERO ).

  the 15 ns is from the clock running at 70 MHz.

  / Lars Segerlund.

Chris Alfred wrote:
>>  Basicly it runs some stuff on the NMI and the 'heavy' tasks on linux 
>>regular interrupts, it can hit a 15 ns window for the code to be run ( 
>>first instruction ) on the MC5246C3 developement board
> 
> 
> Wow! What is the delay from NMI to the code to run.
> 
> . Chris Alfred - Engineering Consultant
> . p: +61 (2) 9566 4470
> . m: 0417 687 437
> . cea at pacific.net.au
> 
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 




More information about the uClinux-dev mailing list