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. > > > > 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. -- Sebastian _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
