[uClinux-dev] realtime scheduling...
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
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
> This message was resent by uclinux-dev at uclinux.org
More information about the uClinux-dev