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

[Wolfgang Grandegger <wg@domain.hid>]

Sebastian Smolorz wrote:
> Wolfgang Grandegger wrote:
>> Access to the parallel port is slow, indeed. Looking to
>> rtcan_peak_dng_epp_readreg tells me, that 6 inb/outb are required to
>> read one register and if every inb/outb takes up 1-2 us ... puh ... the
>> problem gets obvious. Nevertheless, this problem is special for the PCAN
>> dongle and it seems to be a bad choice for RT-Socket-CAN. All other
>> devices can read/write registers much faster. I'm going to do some more
>> tests next week, also with other CAN hardware. Sebastian, have you
>> realized similar latency problems with SJA1000 on the ISA bus (which is
>> slow as well)?
> 
> No, I didn't realize any latency problems with the ISA CAN controller. 
> However, I didn't made any discrete latency measure tests. But the fact that 
> the SJA1000 driver is used on all robots of the RTS with 1 MB/s laser 
> scanners and a few more CAN nodes shows me that the latency impact is not 
> critical.

OK, I did'nt expected that reading approx. 15 bytes is really critical. 
But the problem exists and reading these from the ISA bus likely also 
takes 10..20 us.

>>> Sebastian's opinion is that making it interruptible would be "the
>>> start of chaos". I am sure he knows more about this than I ever will
>>> but only out of academic interest before I sort this problem out
>>> outside the realm of rtcan, I would like to know why.
>> As I see it, the right solution would be to handle the CAN interrupts by
>> a service task and disabled the corresponding IRQ till it's handled. I
>> do not see a real problem with this method,
> 
> I didn't say it's impossible. My point was that making the CAN ISR just 
> interruptible with no other changes is not enough.
> 
>> but it requires substantial 
>> implementation effort.
> 
> Right, and for users who don't have such hardware limits like Roland it is 
> probably more important that CAN interrupts are processed with no deferral. 
> So we would have to deal with both needs. Therefore my statement in a 
> previous mail that all the necessary work won't be done in five minutes.

Well, I know but it already got a rather high position on the wish list.

Wolfgang,