Re: Re: [Rtlinuxgpl] Interrupt Prioritization

On Sun, 1 Jan 2006, Victor Yodaiken wrote:

> On Sun, Jan 01, 2006 at 05:22:22PM -0500, Calin A. Culianu wrote:
>>
>>
>> On Sat, 31 Dec 2005, Der Herr Hofrat wrote:
>>
>
> The design I recommend in RTLinux is to make the ISR very short and have it
> pass the time consuming part to a thread. For example, the ISR can post
> to a semphore and a thread can fill the sound driver buffer.
> Does that work for your application?

I was actually thinking of this and am glad you give me the confidence to 
try it!  Yes, that would work quite nice for my application.  I have 
computed some metrics and it should be theoretically impossible for DMA 
buffers to underrun if I adjust the buffer sizes appropriately.  My 
high-priority task will never run for long enough for the buffers to 
totally drain -- so that will work!!  Thanks for the confidence-booster to 
go with that design!

>
> The problem with hardware priorities is that they are very machine dependent
> and don't seem to add anything that this design does not give better.
>
> What are you doing with the soundcard?

Oh, we are doing some real-time experiment stuff with animals.  Rats 
mainly.  We play sounds in response to their behavior and record off 
neurons in their brain to better understand things about the brain.  We 
need to play the sounds in realtime for several reasons:

1. The sounds are ultra-high frequency, 200 kHz stereo.  Lots of data, and
    a non-realtime OS, even with preemption patches, etc still has the
    theoretical possibility to produce skips and jumps.  We want
    guaranteed, glitch-free sounds.

2. We need to play the sounds in hard realtime.  We can't have variation
    in when the sounds play with respect to the rat's behavior as that
    could drastically wreck havoc on the science we are doing. The sounds
    need to be played at exactly the same time with respect to the external
    events that trigger the sound.  So far we've managed to do it quite
    well using RTlinux!  (This sounds like a testimonial in the making). :)

3. We need to be able to dynamically stop the sounds on a dime, as well.
    Our stopping code has to also ramp the sounds down using a cosine^2
    ramping function.  That works best if implemented in the driver...



>>
>> I see what you are saying about interrupt prioritization has 0 advantage
>> though -- I suppose what I want can be accomplished by the above, right?
>>
>> -Calin
>>
>>
>> _______________________________________________
>> Rtl mailing list
>> [email protected]
>> http://hq.fsmlabs.com/mailman/listinfo/rtl
>> http:/www.rtlinux-gpl.org/
>
> -- 
> ---------------------------------------------------------
> Victor Yodaiken
> Finite State Machine Labs: The RTLinux Company.
> www.fsmlabs.com  www.rtlinux.com
> 1+ 505 838 9109
>
_______________________________________________
Rtl mailing list
[email protected]
http://hq.fsmlabs.com/mailman/listinfo/rtl
http:/www.rtlinux-gpl.org/