Hi
What does this mean? This is as good as it gets?
Hm. To be more verbose on what happens between the beginning of
rtcan_sja_interrupt and rtcan_rcv please remove the "inline" from the
functions rtcan_sja_err_interrupt in the file
ksrc/drivers/can/sja1000/rtcan_sja1000.c line 156 and from the function
rtcan_sja_rx_interrupt in the same file in line 87. Compile your
modules/kernel again and repeat the tracer/latency test.
I assume that most of the time is spent in the latter function where several
SJA HW regs are read out. A slow access to the regs could be the explanation
for the long time the interrupt handler has to spend.
Where are the registers located? On the dongle or are these in the PC?
Just to know whether there might not be a problem with the PEAK device.
Is there any way you could check what the access times are to
rtcan_sja_interrupt on your systems when performing the same experiment
and recieving messages (pref PDO with length 8) over the bus?
I am developing on a pretty high-end machine here, in fact every aspect
almost as fast as is on the market at the moment so its would surprise
me if there is a hardware shortcoming if the registers you speak of are
on the PC.
In the mean time I will try doing as you suggest, I presume you want me
to send the frozen trace to you again after that.
Is it worth while removing the virtual driver from the kernel build and
running over rtcan0. Is there any chance that you have never encountered
this problem
Roland.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
