Re: [Xenomai-help] your pending RT-Socket-CAN problems (was rtcan driver. rtcan_sja_interrupt made interruptible)

[Wolfgang Grandegger <wg@domain.hid>]

roland Tollenaar wrote:
> Hi,
> 
> I need some tutoring again if anyone cares to.
> 
>> Threaded IRQs are no magic bullet. They can only help to push a problem
>> down the priority ladder, curing a problem symptom where possible.
> 
> I keep going on about "interruptible" ISR's. Yet I never see the
> phrase used by anyone else. This either means that "Threaded IRQ's" or

E.g. Linux-rt has "threaded IRQs" (http://lwn.net/Articles/146861/).

> "service-tasks" are implicitly interruptible, i.e. do not hog the CPU
> for themselves exclusively, or I am missing something a lot more
> fundamental? Is a "threaded IRQ" a possible solution because threads
> (even real-time ones) will automatically share the CPU according to
> priority? Is this different to a "service task" as mentioned by
> Wolfgang or are the two basically the same?

Almost, threaded IRQs is a generic framework to manage interrupts by 
threads. The CAN "service task" manages the CAN interrupts by threads.

>> Nevertheless, threaded IRQs for RTDM are planned. The yet open design
>> challenge is how to support driver writers best when they have to switch
>> between both models, e.g. during compile-time (keep in mind, you also
>> have to switch the locking: spinlock<->mutex).
> What is a mutex?

wikipedia mutex!

> This is slightly off the topic but is it ridiculous to ask whether it
> is possible to suppress interrupts from user space?
> 
> A possible work-around to the long reading spell occurred to me in the
> following. I turn my 1ms task into for example a 0.5ms task. By
> releasing interrupt IRQ7 every second time the task is run and
> suppressing it on the other, then by using a corresponding toggle I
> can alternately read-out the can and calculate and set control outputs
> on every second time the task is run.
> I might have a bit of trouble preventing the FIFO buffer on the chip
> to overflow but it would be interesting to know what it takes to
> suppress an interrupt anyway.

This sounds wired. The IRQ is not manageable by the app and device 
polling mode without interrupts is not for-seen by the driver.

Wolfgang.