[uClinux-dev] realtime scheduling...
lars.segerlund at comsys.se
Fri Mar 14 02:31:49 EST 2003
Hmm, yes it can handle that, but I don't really understand why ? I
think I am missing something, since you have an interrupt from an
external source, you don't need to schedule that event, or do you mean
if it can schedule an 'linux interrupt' at a lower priority later ? This
it can do.
It can schedule new events from the interrupts that occur, some small
limitations but not much( due to stacka and such but it can be fixed ).
Perhaps you could lose your NMI clock ? Since it sounds like you only
need the NMI for the external interrupt ? And could schedule realtime on
the highest system priority ?
I also have a 'data dump' device, which act's like a buffer between a
realtime process and a linux character device, so it looks like a fifo
but is not. I wrote this since I needed to dump 15 MB/s from a
industrial PC system to disk, and it would allow me to dump in eccess of
100 MB/s to /dev/null while the system was running a quite heavy
realtime task, I used RT-Linux which was not up to the task, at 1 - 1.5
MB/s through it's 'rt-fifo's' it barfed.
If you put these together It would be possible to couple the execution
of user code to the dumping of data from the realtime part, this makes
some assumptions but it sounds simple.
John Williams wrote:
> Hi Lars,
> Lars Segerlund 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, and most of it
>> should be easily portable to other architectures and constraints, (
>> single timer, multiple timers ). ( also I have some work left on
>> verifying the behaviour of sti cli in the drivers and kernel, ie.
>> estimating worst case for the linux interrupt parts ).
> That's an interesting idea... Could it handle, say, interrupts from
> realtime hardware other than the clock? What I'm thinking is a DSP type
> system, where you have an ADC needing real-time servicing. If you could
> attach it to the NMI (as well as the NMI clock), the handler reads the
> data off the device, puts it in a shared memory FIFO, to be processed by
> a regular uclinux process when next convenient.
> Thinking about doing this on microblaze, which is a softcore (ah,
> infinitely flexible hardware! :) - two separate interrupt controllers on
> the INT and NMI ports of the microprocessor, and two timers. one timer
> drives the NMI (real time) scheduler, the other drives the uclinux
> Hardware that needs real time servicing hangs off the NMI int
> controller, everything else (network controllers, UARTs etc) uses the
> regular intc. Could be very interesting.
> 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