- From: Ian Abbott <abbotti_at_mev.co.uk>
- Date: Tue, 08 Feb 2005 11:23:35 +0000
On 08/02/2005 00:54, Frank Mori Hess wrote: > On Monday 07 February 2005 10:09 am, Ian Abbott wrote: > >>So interrupt driven commands are a bit of a no-no? I thought crappy >>unreliable interrupt timing would be better than even crapper process >>scheduling timing! > > Supporting an externally triggered callback would allow someone to use RTAI > if they need hard rt latency. Your current driver won't work with > comedi's RT support due to your use of tasklets. If you want to simulate > commands, do something like comedi_rt_timer (or enhance comedi_rt_timer) > which would provide a simulated command for any driver that supports an > externally triggered callback. Could you clarify the restrictions on tasklets in an RT environment? In my driver, the interrupt source handler callbacks are called from the hardware interrupt handler, not the tasklet. If it's an RT interrupt, the channel data would be read or written within a guaranteed period after the 'scan' trigger. The tasklet is just there for cleaning up freed handlers. I could clean things up without the tasklet, but it could then spend more time in the interrupt routine calling kfree, as I allow my interrupt source handlers to free themselves! I'll investigate having a separate subdevice to handle interrupt triggers. I'm thinking of a using a 6-channel subdevice with a "virtual" external trigger that fires when any of the channels on the channel list fire. The read value would indicate which trigger(s) have fired. This sort of thing would be much less intuitive to use than the I don't know much about comedi_rt_timer. I'll have to look into that. At the moment, I'm just fixing some potential deadlocks in the existing design. -- -=( Ian Abbott _at_ MEV Ltd. E-mail: <abbotti_at_mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Received on 2005-02-08Z11:23:35