Jan Kiszka wrote:
Klaas Gadeyne wrote:
With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
flawlessly, and moreover, I got excellent latency results:
I used the same kernel config as for our 2.4.31
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Klaas Gadeyne wrote:
With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
flawlessly, and moreover, I got excellent latency results:
I
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Klaas Gadeyne wrote:
With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
flawlessly, and moreover, I got excellent latency results:
I
On 10/14/2005 09:33 PM [EMAIL PROTECTED] wrote:
Hi:
result: total failure. I think that could be the x.org X11 driver
BoardName ATI Radeon (fglrx)
Driver radeon
that cause so many problems.
It's not clear to me what you are speaking about. What failed?
Someone could suggest
On 10/15/2005 11:03 AM [EMAIL PROTECTED] wrote:
Hi:
disabling the Altivec in the kernel kill the X server. Anywai I completd
the Xenomai installation (make menuconfig). Without FP support.
I also observed big latencies with X running on my iBook2.
Now the latency test works (26 min) no
On 10/20/2005 07:59 AM [EMAIL PROTECTED] wrote:
Hi:
I see a lot's of activity around PPC embedded hardware. I'm happy to see
that there is intelligent lifeform beyond x86 :).
I' relatively new to this environnement, so if someone will post a short
list of Xenomai tested PPC embedded
On 10/20/2005 09:06 AM [EMAIL PROTECTED] wrote:
Wolfgang:
thank, BUT your mail does not answer at the question:
I need a list :)
1)
2)
3)
and I will choose the cheapest available ready to run Linux.
Generally, the MPC 5200 is not yet well supported by the stock 2.6
kernel, a MPC 8xx
Randy Smith wrote:
See below...
Behre, Frederik - LT wrote:
Hello
I have following Problem when I Build my uImage from my kernel.
But first my configuration
Host system:
ix86
Suse Linux 10.0 32bit
Cross Compiler
Denx eldk ver. 3.11
(_www.denx.de_ file://www.denx.de)
Target System
PPC
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem
is rather that the memory is not really allocated until you
memset it, which fails when no memory is available. In this
case, calling memset on memory allocated with malloc should
segfault the same way when
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem is
rather that the memory is not really allocated until you memset it,
which fails when no memory is available. In this case, calling memset
on memory allocated
Jan Kiszka wrote:
Landau, Bracha wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
snip
Could you please avoid re-using posted mails for new threads? Thanks.
Two questions regarding rtdm:
1) I would like to use the real-time
Wolfgang Grandegger ([EMAIL PROTECTED]) or Sebastian Smolorz
([EMAIL PROTECTED]).
Credits:
---
See CREDITS file.
License:
---
RTCAN is free software, and you are welcome to redistribute it under
the terms of the GNU General Public License. This program comes with
ABSOLUTELY
GUARDIOLA-FALCO Sebastien 204282 wrote:
jan.kiszka wrote:
== Sampling period: 100 us
== All results in microseconds
RTT| 00:00:01
RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst
RTD| 1.859| 3.239| 6.179| 0| 1.859| 6.179
RTD|
Hi Daniel,
Daniel Schnell wrote:
Hi,
I am new to socket can.
I wanted to test the rtcan driver in combination with Linux and Xenomai
and made a little program according to the rtcansend program but with
some response time measurements.
However after setting up the socket I get
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Daniel,
Daniel Schnell wrote:
Hi,
I am new to socket can.
I wanted to test the rtcan driver in combination with Linux and
Xenomai and made a little program according to the rtcansend program
but with some response time measurements
Jan Kiszka wrote:
Hi all,
Wolfgang Grandegger wrote:
Hi Daniel,
Daniel Schnell wrote:
Hi,
I wanted to use select() on a socket to find out how many messages are
available. I have opened this socket to access the RTCAN sockets under
Xenomai. According to /usr/xenomai/lib/posix.wrappers
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi all,
Wolfgang Grandegger wrote:
Hi Daniel,
Daniel Schnell wrote:
Hi,
I wanted to use select() on a socket to find out how many messages are
available. I have opened this socket to access the RTCAN sockets under
Xenomai. According to /usr
Hi Gilles,
Gilles Chanteperdrix wrote:
[EMAIL PROTECTED] wrote:
Dear Gilles,
I admit, the mechanism for allocating all memory of the target is not very sophisticated. The idea was, that MAXHEAPBLOCKS*MEMORYCHUNKSIZE is much much more, than memory available (at least with my target
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] :
Ok. Now the question remains: does this problem still exist
with version
2.2.2 ? The heaps overhead computations have changed recently.
Good news. I can´t reproduce the seg. fault with 2.2.2 although I tried hard
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] :
Ok. Now the question remains: does this problem still exist
with version
2.2.2 ? The heaps overhead computations have changed recently.
Good news. I can´t reproduce the seg. fault with 2.2.2 although I tried hard
Syed Amer Gilani wrote:
I have a custom mpc5200 Board with needs patches to get Linux running
on it. But those Patches are only available for 2.6.17. Before i try
to backport those patches i just wanted to ask if there is a way to
run Xenomai on 2.6.17 for ppc.
I posted a commented ADEOS-IPIPE
Syed Amer Gilani wrote:
2006/9/30, Wolfgang Grandegger [EMAIL PROTECTED]:
I realized, that the differences to Linux 2.6.18 are quite small and non
critical. Attached is a ADEOS-IPIPE patch for Linux 2.6.17, which should
work on your MPC5200 as well (the idle loop problem for 6xx is solved
Syed Amer Gilani wrote:
2006/9/30, Wolfgang Grandegger [EMAIL PROTECTED]:
Syed Amer Gilani wrote:
2006/9/27, Wolfgang Grandegger [EMAIL PROTECTED]:
I posted a commented ADEOS-IPIPE patch for 2.6.18 for PPC end of last
week (see
https://mail.gna.org/public/adeos-main/2006-09/msg9.html
Syed Amer Gilani wrote:
I wanted to test rtcan but the mscan Driver fails to compile:
CC drivers/xenomai/can/mscan/rtcan_mscan.o
drivers/xenomai/can/mscan/rtcan_mscan.c:85: error: syntax error before
string constant
drivers/xenomai/can/mscan/rtcan_mscan.c:85: warning: type defaults to
runs at 33 MHz on your system.
Wolfgang.
Index: ChangeLog
===
--- ChangeLog (revision 1695)
+++ ChangeLog (working copy)
@@ -1,3 +1,18 @@
+2006-10-06 Wolfgang Grandegger [EMAIL PROTECTED]
+
+ * ksrc/drivers/can/rtcan_module.c
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Index: ksrc/drivers/can/rtcan_internal.h
===
--- ksrc/drivers/can/rtcan_internal.h (revision 1695)
+++ ksrc/drivers/can/rtcan_internal.h (working copy)
@@ -111,6 +111,10
Ji Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Index: ksrc/drivers/can/rtcan_internal.h
===
--- ksrc/drivers/can/rtcan_internal.h(revision 1695)
+++ ksrc/drivers/can
Jan Kiszka wrote:
Frits de Klark wrote:
Hello everyone,
I'm in the need of a realtime CAN driver which is as fast as possible
and at
the same time user-friendly. The RT socket CAN driver looks rather
appealing
to me, but I'm wondering if there's any negative impact on speed (in the
context of
Frits de Klark wrote:
Hello everyone,
as sort of a newbie to Xenomai (and realtime Linux in general) I'm the
moment running the (unmodified) latency test included in the testsuite
in different situations:
Situation A: Running as little daemons as possible in the background.
The chart I
Jan Kiszka wrote:
[EMAIL PROTECTED] wrote:
Just to be sure :
Does the access of a mmaped address (real_mmamp of a device file e.g.
/dev/dualportmemory) force Xenomai to switch to secondary mode ?
I would say yes, as the access of the address probably results into a
read/write of the device
Thomas Witzel wrote:
On Wednesday 01 November 2006 01:58, Romain Lenglet wrote:
Since you wanted to develop/port your own device driver anyway, I
just suggested to use JACK as an interface with your
applications, instead of the ALSA interface. I believe that the
JACK API/interface is better
Frits de Klark wrote:
Hello everyone,
I'm not sure this is the right place to ask about it, but is the virtual
CAN driver mentioned in [1] of any use if I want to develop an
application using RT Socket CAN? If so, how do I set it up (just patch
the xenomai-root I guess) and how do I use it?
Daniel Schnell wrote:
Hi,
I am struggling with Xenomai latest SVN and RT-Socket-CAN on a MPC5200B
with MSCAN driver inside a Denx 2.4.25 kernel.
Does anybody have this configuration actively running ? How do you use
Yes.
the provided rtcansend/rtcanreceive functions, so they actually
Frits de Klark wrote:
Hi,
do you mean I should have better provided a patch? I'd love to do so,
but I'm not (yet) much of a Linux developer and I've never created a
patch before. But I guess there's no escaping the need of learning how
to do so very soon :)
You checkout Xenomai from the
Jan Kiszka wrote:
Frits de Klark wrote:
Hello everyone,
I finally got my PCI CAN card today. It's an Advantech 1680 and
provides, as
far as I'm informed, a memory mapped SJA1000 controller.
I´m trying to load the xeno_rtcan_mem module now, but I'm not sure what
parameters I should pass. More
Jan Kiszka wrote:
Frits de Klark wrote:
Hi,
to get back on my earlier question: IF the memory mapping might work for
me,
how should I call it?
The PCI card has two CAN ports. Here's (a part of) the output of lspci -vv:
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e1003000 (32-bit,
Frits de Klark wrote:
Hello,
Well, my first tests look very promising. Using your rtcansend and
rtcanrecv utilities and a cable between port 1 and port 2 on my card,
the messages arrive perfectly.
I'm off to do some more testing. If I run into any strange situations,
I'll let you know.
Jan Kiszka wrote:
Daniel Schnell wrote:
Hi,
If one opens two sockets to one CAN port and wants to use one socket
file descriptor for reading and the other for writing, is it possible to
limit the writing socket to _write only_, so it doesn't receive messages
?
Note that the messages are
naming scheme. I have attached the full ChangeLog entry.
Any feedback is welcome, also on the new TX-Loopback feature.
Wolfgang.
2006-11-24 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/README: Update list of supported CAN controllers
and boards.
* ksrc
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
I have just commited various modifications and improvements for
RT-Socket-CAN to the SVN trunk (v2.3-devel). The modification you might
realize sooner than later is the renaming of the RT-Socket-CAN kernel
modules from xeno_rtcan_
Jan Kiszka wrote:
Hi,
the new Xenomai example repository has been created. I don't want to
repeat here what is explained already on the related wiki page, please
have a look at
http://www.xenomai.org/index.php/Examples
Instead, let me sketch what could be done next:
o Port existing
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi,
the new Xenomai example repository has been created. I don't want to
repeat here what is explained already on the related wiki page, please
have a look at
http://www.xenomai.org/index.php/Examples
Instead, let me sketch
Philippe Gerum wrote:
On Fri, 2006-12-01 at 18:22 +0100, Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi,
the new Xenomai example repository has been created. I don't want to
repeat here what is explained already on the related wiki page, please
have a look at
http
Jan Kiszka wrote:
Daniel Schnell wrote:
Hi,
If one opens two sockets to one CAN port and wants to use one socket
file descriptor for reading and the other for writing, is it possible to
limit the writing socket to _write only_, so it doesn't receive messages
?
Option 1: Do not bind the
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi,
the new Xenomai example repository has been created. I don't want to
repeat here what is explained already on the related wiki page
Frits de Klark wrote:
Hello everyone,
I noticed that the sizeof() function reports that the struct can_frame
has a size of 16 bytes. I know that this is because of memory aligning
done by the GNU compiler.
This is just a structure to pass message data from and to the CAN driver.
But now I
Hi Antonio,
I re-added the ADEOS and Xenomai mailing lists to CC because others
might be able to help better.
[EMAIL PROTECTED] wrote:
Thanks for testing. And please read the complete thread at
http://ozlabs.org/pipermail/linuxppc-embedded/2006-December/thread.html#25455
containing some more
Niklaus Burren wrote:
Hello
Im trying to create a Xenomai kernel module for a ARM processor
(PXA-270). In this module I register a interrupt handler with the
function rt_inter_create(). When I compile the module I get the
following warnings:
*** Warning: rt_intr_delete
Niklaus Giger wrote:
Hi
I tried to use the FIT (Fixed Interrupt Timer) on my PPC405GPr board, which
uses 0x1010 as its interrupt vector in a user space (vxworks-skin)
application.
..
RT_INTR FITnterrupt;
res = rt_intr_create(FITnterrupt, 0, 0x1010, I_NOAUTOENA);
..
But I got -22 EINVAL
[EMAIL PROTECTED] wrote:
When I try to prepare the kernel with xenomai-2.3-rc2 I get the
following error :
find: xenomai-2.3-rc2/sim: file or directory not found
The Prepare command I use :
scripts/prepare-kernel.sh --linux=/home/user/linuxppc --arch=ppc
Does anybody know what this means ?
[EMAIL PROTECTED] wrote:
The missing directory will not harm. Anyhow, if you start
It does harm, as the kernel is prepared only partialy and make
menuconfig crashes.
Ah, OK. A quick hack is to remove sim from prepare_kernel.sh, or
better use -rc3.
testing 2.3-rcX now, please use
[EMAIL PROTECTED] wrote:
With 2.3-rc3 I get a new problem preparing the kernel :
Can't open perl script /home/user/xenomai-2.3-rc3/scripts/help_from_kconfig.pl:
Datei oder Verzeichnis nicht gefunden
Argh, something went really wrong preparing the rc releases.
Any suggestions how I can get
Hi Daniel,
Daniel Schnell wrote:
Hi,
I want to patch the latest Denx 2.4.25 kernel with Xenomai-2.3.0
The prepare-kernel.sh skript fails with the following message:
[EMAIL PROTECTED] xenomai-2.3.0]# scripts/prepare-kernel.sh --arch=ppc
Daniel Schnell wrote:
Wolfgang Grandegger wrote:
I unable to reproduce your problem with a fresh linuxppc_2_4_devel
tree and xenomai-2.3.0. Could you please use the --verbose option
with prepare_kernel.sh and post the result.
Hmm, I used
make mrproper; git pull
to get the latest deltas
Wolfgang Grandegger wrote:
Daniel Schnell wrote:
Wolfgang Grandegger wrote:
I unable to reproduce your problem with a fresh linuxppc_2_4_devel
tree and xenomai-2.3.0. Could you please use the --verbose option
with prepare_kernel.sh and post the result.
Hmm, I used
make mrproper; git
Hello,
you program does not use Xenomai services and is therefore off-topic
here, nevertheless...
mani bhatti wrote:
Hi
I have attached a kernel module parint.c.When i insert parint.ko into
kernel i get the following message from kernel .
Request_irq returns 0
Interrupt generated. You
-21 13:04:44.0 +0100
@@ -0,0 +1,402 @@
+/*
+ * Round-Trip-Time Test - sends and receives messages and measures the
+ *time in between.
+ *
+ * Copyright (C) 2006 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * Based on RTnet's examples/xenomai/posix/rtt-sender.c
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Roland Tollenaar wrote:
Hi list,
does anyone have, or can anyone direct met to a project or code-snippet
that shows how the CAN driver in the xenomai patch is used in an
application? If not that any documentation that gives
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
[...]
I have attached a patch for a nice program to measure
the round trip time of CAN messages. It contrast to the other CAN
utility programs, it uses the POSIX-API and works as-is for Socket-CAN
as well. Jan, any objections to include it? If yes
why i have no devices listed in
proc/rtcan/devices?
Without device it will not register anyhow and see above.
Wolfgang.
On 2/22/07, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
roland Tollenaar wrote:
Hi Jan,
rtcanX are networking devices, but only visible in the context of
RTDM/AF_CAN
, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
roland Tollenaar wrote:
Hi Jan,
rtcanX are networking devices, but only visible in the context of
RTDM/AF_CAN.
What is this?
To enable them, use rtcanconfig as explained in the README.
Which README are you referring to? The only one I know
rtcan: registered rtcan0
rtcan0: VIRT driver loaded
rtcan: registered rtcan1
rtcan1: VIRT driver loaded
Xenomai itself must be running because the the programs in the
testsuite seem to be working.
Roland
On 2/22/07, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
roland Tollenaar wrote:
Hi
On 2/22/07, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
roland Tollenaar wrote:
Hi Wolfgang,
sorry to ask a stupid question here but where would I find the complete
boot log
I am checking /var/log/
but am not sure which one you would want?
Output of dmesg please or the log of your
roland Tollenaar wrote:
Hi Wolfgang,
And /proc/rtcan/devices is also useful.
Device rtcan0 Baudrate undefined State active TXCounter 7 RXCounter 5
Errors 0
Device rtcan1 Baudrate undefined State stopped TXCounter 0 RXCounter 0
Errors 0
virtual can with? I presume i can send it messages
Roland Tollenaar wrote:
Hi Wolfgang,
I said, it can be statically linked into the kernel but it will not
work
(without modification, we can discuss this issue when you have a PCAN
dongle). What should a driver without hardware be good for?
Good question. On the other hand it would be useful
Roland Tollenaar wrote:
Hi,
Invoke make like this: make /path to xeno-config/. Which is why I was
going on about the config variables. I wil now try and find
xeno-config if it exists and see how that works. On the other hand I
don;t doubt that the application will compile. I need to find out
roland Tollenaar wrote:
Hi,
I am looking through the rtcan code provided with the xenomai package
and I realize one thing:
I know too little of the basic socket programming. Not even sure my
wording in the previous sentence is capturing the correct area of
ignorance.
There are plenty text
roland Tollenaar wrote:
Hi
Xenomai kernel implements the so-called FIFO scheduling policy, that
is, the task which runs at any time is the task with the highest
priority that has been ready for the longest time. Calling
rt_task_wait_period suspends the calling task, and let other tasks
run.
roland Tollenaar wrote:
And follow the links, you will arrive at:
http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html
Actually this is where I had been spending most of my time before
posting my mail.
I must be blind because I really do not see anything remotely
resembling
roland Tollenaar wrote:
Hi,
You must all be getting very exasperated with me. :)
Why, you seem to be exasperated ;-).
I know too little of the basic socket programming. Not even sure my
wording in the previous sentence is capturing the correct area of
ignorance.
There are plenty text
Jan Kiszka wrote:
Roland Tollenaar wrote:
Hi Jan,
Err? What are practical cases for you?
Both modes are _debugging_ features.
Huh? There only seem to be two flavours. Listen_only or loopback. Are
you saying that for normal operation it does not matter at all what the
setting is? I.e. don't
roland Tollenaar wrote:
HI
That seems to be due to non-default -Wmissing-field-initializers, right?
Will have a look if we can quiet gcc.
Possible. I have received your patch. Will apply it (have to figure
out how first) later and give feedback.
If rtcanrecv is not running then my
roland Tollenaar wrote:
Hi,
Ok the issue I posted earlier regarding the read function. It seems
that it IS recieving can messages and displaying them correctly. Only
its behaviour is not as I expected. I thought the function
rt_dev_recvfrom
would simply perform a read one frame from a buffer
Roland Tollenaar wrote:
Hi Wolfgang,
Can this be confirmed or is rt_dev_recvfrom() behaving incorrectly in
my case?
rt_dev_recvfrom() reads message frames (one at a time) from an
internal socket buffer (there is actually a kernel configuration
option to configure the size). If no messages
roland Tollenaar wrote:
Hi,
My dongle has arrived and seems to be OK under windows.
I am now trying to install it under linux but things not looking good so
far.
from
/lib/modules/2.6.16-xen-3/kernel/drivers/xenomai/can/sja1000
I ran
$depmod xeno_can_peak_dng.ko
$modprobe
Jan Kiszka wrote:
roland Tollenaar wrote:
Hi,
My dongle has arrived and seems to be OK under windows.
I am now trying to install it under linux but things not looking good so
far.
from
/lib/modules/2.6.16-xen-3/kernel/drivers/xenomai/can/sja1000
I ran
$depmod xeno_can_peak_dng.ko
roland Tollenaar wrote:
FATAL: Error inserting xeno_can_peak_dng (xeno_can_peak_dng.ko): No
such
device
Is there som additional kernel output visible via dmesg?
Yes:
SCSI device sdb: 3963904 512-byte hdwr sectors (2030 MB)
sdb: Write Protect is off
sdb: Mode Sense: 43 00 00 00
sdb:
Markus Franke wrote:
I had the same problems with a parallelport dongle. When I removed the
modules parport_pc and lp the parallel port device was always
powered off and it was not possible to receive interrupts anymore. A
workaround for this power off was to append pnpbios=off-option to
the
roland Tollenaar wrote:
Hi,
My situation is slightly different. The modules don;t get loaded for
some or other reason (not sure why because I do have parport support
M selected in the kernel config.
My BIOS settings said ECP instead of EPP ( I still don;t know the
difference) I set it to EPP
roland Tollenaar wrote:
Hi,
One question. The driver loads properly but is that a guarantee that
everything is fine? Without anything connected to it what is the best
manner to check its correct functioning?
Remember the special modes. You could configure the loopback mode of
the device
roland Tollenaar wrote:
Hi,
Ok rtcan2 and the peak dongle seem to be working. I am now running
into new problems with my application.
The first question is how do I reset the ctrl_mode to nothing.
Listen-only and loopback are both debugging/testing states but how do
I reset them to what is
Hi Roland,
hope most of your problems and questions with RT-Socket-CAN have already
been solved or answered. I will not have the time to read carefully all
your mails accumulated over the last week, sorry, it's too much traffic.
Could you please briefly summarize the pending issues.
Thanks,
Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Note that the current implementation of RT-Socket-CAN shows this
behaviour on purpose. See also [1] (may flood!). Whether this is the
right handling or not may be
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
Hallo,
in the meantime I have measured the latencies introduced through
messages sent and received by RT-Socket-CAN. The SJA1000 register access
times on my rather old PC with an Athlon 1100 Mhz are:
PEAK-Dongle: read access: 11807 ns
PEAK-Dongle: write access: 11677 ns
IXXAT-PCI : read
Roland Tollenaar wrote:
HI Wolfgang,
It was the IXXAT PCI card currently plugged into my test PC but I
actually recommand the PEAK PCI card. It's also much cheaper, I guess.
Tomorrow I'm going to repeat the tests with this card ... stay tuned.
Clear. Thanks for the advice.
I will continue
this load that is always
talked about?
Roland
Wolfgang.
Thanks,
Roland
Wolfgang Grandegger wrote:
Hallo,
in the meantime I have measured the latencies introduced through
messages sent and received by RT-Socket-CAN. The SJA1000 register
access times on my rather old PC with an Athlon
[EMAIL PROTECTED] wrote:
I want to measure and evalutate different parameters of system load in
Xenomai. Therefore, I am in need of RT samples that simply provide a
variety of ressource usage (semaphores, threads, timers, ...).
Have a look on http://svn.gna.org/svn/xenomai/trunk/examples/
Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Note that the current implementation of RT-Socket-CAN shows this
behaviour on purpose. See also [1] (may flood!). Whether this is the
right handling or not may be
Daniel Schnell wrote:
Hi,
Sorry to repost this issue, which I posted some days ago, but there was
no reaction so far.
It should be easy to reproduce. I need just a short answer from somebody
with a RT-CAN driver.
Hm, Gilles already answered
Sebastian Smolorz wrote:
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
Last summer we had a discussion about the BEI issue on the socketcan-ML.
Two additional handling policies popped up:
1. The interface could restart itself after an amount of BEIs, thus
taking responsibility from
Hi Sebastian,
Sebastian Smolorz wrote:
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
Last summer we had a discussion about the BEI issue on the socketcan-ML.
Two additional handling policies popped up:
1. The interface could restart itself after an amount of BEIs, thus
taking
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Back to our preferred solution 1. Attached is a patch for review
including some other fixes and suggestions accumulated over time:
* ksrc/drivers/can/*: To avoid unnecessary bus error interrupt
flooding, the option
make the implementation simpler. I have to check.
Wolfgang.
Wolfgang Grandegger wrote:
Hi Sebastian,
Sebastian Smolorz wrote:
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
Last summer we had a discussion about the BEI issue on the
socketcan-ML.
Two additional handling policies popped
Sebastian Smolorz wrote:
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
you know, on the SJA1000 the bus error interrupt can result in high
error interrupt rates and even hang the system on slow processors. Just
unplugging the CAN cable can cause such interrupt flooding. This problem
Sebastian Smolorz wrote:
Sebastian Smolorz wrote:
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
you know, on the SJA1000 the bus error interrupt can result in high
error interrupt rates and even hang the system on slow processors. Just
unplugging the CAN cable can cause such interrupt
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
Sebastian Smolorz wrote:
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
you know, on the SJA1000 the bus error interrupt can result in high
error interrupt rates and even hang the system on slow processors.
Just
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
Sebastian Smolorz wrote:
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
you know, on the SJA1000 the bus error interrupt can result in high
error interrupt rates and even hang the system
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
The problem is to define what degree of error-related IRQ load is
generally acceptable. We surely can't do this, so we have to document
the effect /at least/ and help the users to check it on their own - or
we have to avoid it / make it insignificant
that worst case latencies of better than 20us are
difficult to achieve, even with high end PCs.
Wolfgang.
Kind regards,
Roland
Roland
Wolfgang.
Thanks,
Roland
Wolfgang Grandegger wrote:
Hallo,
in the meantime I have measured the latencies introduced through
messages sent
1 - 100 of 301 matches
Mail list logo
