From: Philippe Gerum <rpm@xenomai.org>
To: smannori@domain.hid
Cc: xenomai@xenomai.org, wjasper@domain.hid
Subject: Re: [Xenomai-help] Interrupt Shied (II)
Date: Tue, 20 Dec 2005 09:01:27 +0100 [thread overview]
Message-ID: <43A7BA57.1030801@domain.hid> (raw)
In-Reply-To: <38197.128.93.15.41.1135063005.squirrel@domain.hid>
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.
prev parent reply other threads:[~2005-12-20 8:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43A7BA57.1030801@domain.hid \
--to=rpm@xenomai.org \
--cc=smannori@domain.hid \
--cc=wjasper@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.