Hi,
Thanks for the input. Much appreciated from my side. I cannot comment on
your question
> The net result was that we had to add quite a lot of udelay() calls
to >slow down the driver to the senator's pace of the SJA1000... Are you
>sure you're not running in this kind of problem?
but if anyone has suggestions as to what I can do to validate it I would
be happy to try. (Sebastian your request to remove the inline statement
is forthcoming)
For the record, I am developing on a laptop with 3 GHz Intel CPU, 2 GB
of RAM, 800 Mhz FSB and that is about all the stats I have. This info is
probably irrelevant but just to clear out of the way any ideas that I
might be working on the oldest of PC hardware.
I do have a question which may be a bit early or out of context but if
it turns out without question that the delay IS in the
rtcan_sja_interrupt
routine (is it a routine? A function call? ) would it be possible to
split the function up into smaller parts (is this what they call
granularity?) so that the RT tasks can return to themselves before
running out of time while stuck in the rtcan_sja_interrupt call. ?
Or am I missing the point entirely?
Regards,
Roland.
Bernard Dautrevaux wrote:
Hi everybody,
Maybe I'm making an error, but AFAIK, the SJA1000 on-chip registers are clocked by a rather slow clock, that is limited to about 24MHz. I remember a case where interrupts were handled by the CPU (a 600MHz thing) too fast for the SJA1000, resulting in the chip not yet aware that it generates the interrupt.
To be more precise, the IRQ gets out, probably immediately through some sort of
asynchronous logic, but the fact was only clocked in the interrupt status
register at about 16MHz, thus the CPU was able to read the interrupt status
register, thus clearing the coming interrupt state, before the interrut was
latched, and thus the IRQ was lost...
The net result was that we had to add quite a lot of udelay() calls to slow
down the driver to the senator's pace of the SJA1000... Are you sure you're not
running in this kind of problem?
Just my .02€
Bernard
-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Sebastian Smolorz
Envoyé : jeudi 8 mars 2007 15:13
À : [EMAIL PROTECTED]
Cc : [email protected]
Objet : Re: [Xenomai-help] RTCAN and tsc
Roland Tollenaar wrote:
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?
These are registers located in the SJA1000 CAN controller.
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?
Unfortunately, I do not have the opportunity to perform tests
with the driver ATM.
I am developing on a pretty high-end machine here,
Didn't you speak of 486's in a previous mail?
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.
Exactly.
Is it worth while removing the virtual driver from the kernel build
and running over rtcan0.
Turn it off although it is unlikely that it has something to
do with the problem. But you never know.
Is there any chance that you have never encountered this problem
I never worked with the virtual device.
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
