* [Xenomai-help] Interrupt Shied (II)
@ 2005-12-20 7:16 smannori
2005-12-20 7:45 ` Jan Kiszka
2005-12-20 8:01 ` Philippe Gerum
0 siblings, 2 replies; 3+ messages in thread
From: smannori @ 2005-12-20 7:16 UTC (permalink / raw)
To: xenomai; +Cc: wjasper
Hi everybody:
I installed xenomai 2.1 on a little Celeron M laptop with SiS chipset
(distro : fedora core 3, kernel : linux-2.6.14.3-ipipe) :
00:00.0 Host bridge:
Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS]: Unknown device 0003
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media
IO] (rev 25)
00:02.1 SMBus:Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.6
Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
00:02.7 Multimedia audio controller:
Silicon Integrated Systems [SiS] Sound Controller (rev a0)
00:03.0 USB Controller:
Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller:
Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI
Fast Ethernet (rev 90)
00:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
00:09.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
00:09.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev
04) 00:0e.0 Network controller: Intersil Corporation ISL3886 [Prism
Javelin/Prism Xbow] (rev 01)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
661FX/M661FX/M661MX/741/M741/760/M760 PCI/AGP
I left the SMI detection active, but I don't have warning message because
SiS does NOT use SMI interrupt. As I know, everything works OK.
I want to use a little USB data acquisition board USB-1208FS , because some
brave soul ( Warren J. Jasper ) has developed a generic linux library for
this card, including some good documentation an VERY GOOD test programs
(useful for "Dummies Like Me (@TM)" ).
This board is garantee to reach 250 S/s. On my PC, without Xenomai, the
maximum free-running speed is 330 S/s.
My idea is to use a real time xenomai task to pace the data acquisition. As
demo, I'm generating a square wave with the internal DAC to hear the results
on a little piezoelectric speaker. It's sound good :).
To show the dramatic difference bettewen real time and standard Linux, I'm
using the usual usleep() function to generate soft realtime square wave on
the second DAC channel. If run the program leaving the PC idle, the two
channels sound almost equal. If a begin to load the CPU, the real time sound
remain steady and clear BUT the other show jitter and "hole" (no sound).
The demo is really dramatic when the audience realize that the SAME HARDWARE
on the SAME I/O chanel can be used in "dual mode" seamless :o.
Now the problems:
1) If I push the sample rate above 50 S/s the progam starts, but, after a
while, the real time square wave disappear. Also the "SquareWave" task
disappear from /proc/xenomai/sched.
2) it is not a problem of interaction with the NON realtime square wave
because the same behavior remain if I remove the code
3) I tried the same program on the PPC achitecture using a PowerBook with
similar results.
Where is the catch ? I missed something around the interrupt shield ?
I need to develop real-time application using USB devices because we need
something usable with a laptop. Unfortunately USB is NOT supported for real
time applications and I'm not competent enough to write my real time USB
driver.
My hope is that the interrupt shield of Xenomai will save my day :)
Simone Mannori
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xenomai-help] Interrupt Shied (II)
2005-12-20 7:16 [Xenomai-help] Interrupt Shied (II) smannori
@ 2005-12-20 7:45 ` Jan Kiszka
2005-12-20 8:01 ` Philippe Gerum
1 sibling, 0 replies; 3+ messages in thread
From: Jan Kiszka @ 2005-12-20 7:45 UTC (permalink / raw)
To: smannori; +Cc: xenomai-help, wjasper
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
smannori wrote:
> ...
> Now the problems:
>
> 1) If I push the sample rate above 50 S/s the progam starts, but, after a
> while, the real time square wave disappear. Also the "SquareWave" task
> disappear from /proc/xenomai/sched.
Any segfaults? Take a look at /proc/xenomai/faults (if I remember this
entry name correctly now).
>
> 2) it is not a problem of interaction with the NON realtime square wave
> because the same behavior remain if I remove the code
>
> 3) I tried the same program on the PPC achitecture using a PowerBook with
> similar results.
>
> Where is the catch ? I missed something around the interrupt shield ?
>
> I need to develop real-time application using USB devices because we need
> something usable with a laptop. Unfortunately USB is NOT supported for real
> time applications and I'm not competent enough to write my real time USB
> driver.
> My hope is that the interrupt shield of Xenomai will save my day :)
>
It may improve the number of deadline misses, but it will not make them
disappear. The standard Linux stack may do things in your back while you
do some data acquisition, and you cannot control this. Moreover, you can
suffer from low buffers when trying to issue some request to the stack,
and this is also something you cannot influence as the buffers are taken
from global pools.
I'm hopefull that we (well, it's going to be outsourced: a student) will
be able to revise the existing USB4RT stack (=>RTDM port), derive or
define an interface for high-layer drivers like your USB DAQ requires,
and then someone could port things over... :) Actually, USB becomes more
and more important for hard-RT. One just have to think of all those
<X>2USB devices (replace <X> with RS232, CAN, etc.) for boxes with
otherwise limited extensibility.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xenomai-help] Interrupt Shied (II)
2005-12-20 7:16 [Xenomai-help] Interrupt Shied (II) smannori
2005-12-20 7:45 ` Jan Kiszka
@ 2005-12-20 8:01 ` Philippe Gerum
1 sibling, 0 replies; 3+ messages in thread
From: Philippe Gerum @ 2005-12-20 8:01 UTC (permalink / raw)
To: smannori; +Cc: xenomai, wjasper
smannori@domain.hid wrote:
> Hi everybody:
>
> I installed xenomai 2.1 on a little Celeron M laptop with SiS chipset
> (distro : fedora core 3, kernel : linux-2.6.14.3-ipipe) :
>
> 00:00.0 Host bridge:
> Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
> 00:01.0 PCI bridge: Silicon Integrated Systems [SiS]: Unknown device 0003
> 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media
> IO] (rev 25)
> 00:02.1 SMBus:Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
> 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.6
> Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
> 00:02.7 Multimedia audio controller:
> Silicon Integrated Systems [SiS] Sound Controller (rev a0)
> 00:03.0 USB Controller:
> Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
> 00:03.1 USB Controller:
> Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
> 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
> 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI
> Fast Ethernet (rev 90)
> 00:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
> 00:09.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
> 00:09.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev
> 04) 00:0e.0 Network controller: Intersil Corporation ISL3886 [Prism
> Javelin/Prism Xbow] (rev 01)
> 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
> 661FX/M661FX/M661MX/741/M741/760/M760 PCI/AGP
>
> I left the SMI detection active, but I don't have warning message because
> SiS does NOT use SMI interrupt. As I know, everything works OK.
>
> I want to use a little USB data acquisition board USB-1208FS , because some
> brave soul ( Warren J. Jasper ) has developed a generic linux library for
> this card, including some good documentation an VERY GOOD test programs
> (useful for "Dummies Like Me (@TM)" ).
>
> This board is garantee to reach 250 S/s. On my PC, without Xenomai, the
> maximum free-running speed is 330 S/s.
>
> My idea is to use a real time xenomai task to pace the data acquisition. As
> demo, I'm generating a square wave with the internal DAC to hear the results
> on a little piezoelectric speaker. It's sound good :).
>
> To show the dramatic difference bettewen real time and standard Linux, I'm
> using the usual usleep() function to generate soft realtime square wave on
> the second DAC channel. If run the program leaving the PC idle, the two
> channels sound almost equal. If a begin to load the CPU, the real time sound
> remain steady and clear BUT the other show jitter and "hole" (no sound).
>
> The demo is really dramatic when the audience realize that the SAME HARDWARE
> on the SAME I/O chanel can be used in "dual mode" seamless :o.
>
> Now the problems:
>
> 1) If I push the sample rate above 50 S/s the progam starts, but, after a
> while, the real time square wave disappear. Also the "SquareWave" task
> disappear from /proc/xenomai/sched.
>
> 2) it is not a problem of interaction with the NON realtime square wave
> because the same behavior remain if I remove the code
>
> 3) I tried the same program on the PPC achitecture using a PowerBook with
> similar results.
>
> Where is the catch ? I missed something around the interrupt shield ?
>
You could try to strace your app and log the output, so that the cause
of the thread exit might be identified more easily. Running it under GDB
is another option to detect unexpected faults.
> I need to develop real-time application using USB devices because we need
> something usable with a laptop. Unfortunately USB is NOT supported for real
> time applications and I'm not competent enough to write my real time USB
> driver.
> My hope is that the interrupt shield of Xenomai will save my day :)
>
Nb: The I-shield will prevent a real-time task running in secondary mode
to be preempted by Linux interrupts, but it won't make non-RT kernel
code become deterministic.
> Simone Mannori
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-12-20 8:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-20 7:16 [Xenomai-help] Interrupt Shied (II) smannori
2005-12-20 7:45 ` Jan Kiszka
2005-12-20 8:01 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.