I had a similar problem but in reverse - I needed multiple readers on
the one fifo. The easiest solution was to have a user space program
read the fifo and then store the data in a separate queue for each
reader. Readers connect via tcp/ip. Doing the same for fifo writes
from user space would b
On Thu, Dec 14, 2000 at 11:37:29AM -0500, Stephen D. Cohen wrote:
> Hi,
>
> David Olofson offered an excellent treatise on why multiple open of a
> FIFO is a bad idea. I would like to offer a fairly simple solution.
>
> Simply create a block of FIFOs on the RTL side of the hou
On Thu, Dec 14, 2000 at 01:15:14PM +0100, David Olofson wrote:
> Thu, 14 Dec 2000 Eric Peterson wrote:
> > Hi,
> >
> > I'm trying to use RT-Linux (2.2) RT-FIFOs, and I have come up against
> > an apparent limitation with them: they only allow one writer (on the
> > Linux side) to
On Thu, Dec 14, 2000 at 10:50:33AM -0500, Victor Iannello wrote:
> Paolo,
>
> Paolo,
>
> You are confirming what we suspected--the variation in time required to
> access the timer is a symptom rather than the cause of the jitter. You
> mention three possible causes at the hardware level--bus con
Did you to the following in the rtl directory before trying to run the
examples ? This needs to be done after you do the kernel to get the rt
modules ready
make mrproper
make
make install
See the INSTALL.phil (I think that's the name) or the README.
Janet
-Original Message-
From: Le
Thu, 14 Dec 2000 Stephen D. Cohen wrote:
> Hi,
>
> David Olofson offered an excellent treatise on why multiple open of
> a FIFO is a bad idea. I would like to offer a fairly simple solution.
>
> Simply create a block of FIFOs on the RTL side of the house. Attach
> them all to the s
sam gordji wrote:
> I understand that u see the output on a Oscilloscope. I was wondering
> is there any other way we can check out the length of time slices for
> linux.
The gettimeofday() call has excellent resolution, try it in a periodic
handler instead of using an oscilloscope.
static l
Hi,
David Olofson offered an excellent treatise on why multiple open of
a FIFO is a bad idea. I would like to offer a fairly simple solution.
Simply create a block of FIFOs on the RTL side of the house. Attach
them all to the same handler (it gets the FIFO number when it is cal
Victor Iannello wrote:
>
> Paolo,
>
> Paolo,
>
> You are confirming what we suspected--the variation in time required to
> access the timer is a symptom rather than the cause of the jitter. You
> mention three possible causes at the hardware level--bus contention, DMA
> steals, and cache disrup
[EMAIL PROTECTED] wrote:
>
> Hello,
>
> I've found a nicely "undocumented feature", in the semaphore package. I discovered
>that when you initialise a semaphore with a zero count. Although everything seems to
>wors fine. this means any process that do a rt_sem_wait actually wait until another
Paolo,
Paolo,
You are confirming what we suspected--the variation in time required to
access the timer is a symptom rather than the cause of the jitter. You
mention three possible causes at the hardware level--bus contention, DMA
steals, and cache disruption. We have done some experiments with t
Victor Iannello wrote:
>
> If I understand correctly, you are attributing a large cause of the jitter
> to be read and write operations to timer registers. Because a read of the
> timer register(s) is performed even in periodic mode, there is corresponding
> jitter.
There is no timer reading in
Hello,
I've found a nicely "undocumented feature", in the semaphore package. I discovered
that when you initialise a semaphore with a zero count. Although everything seems to
wors fine. this means any process that do a rt_sem_wait actually wait until another
task
make a rt_sem_signal, you h
Are you positive that the pointer, S->StructChild, has a good value? If
it's uninitialized, it could be pointing anywhere (even to the computer on
my desk) and that could give you the paging error.
Norman Dresner
Systems Engineer
Radar Systems Engineering Department
Electronic Systems and Sensor
Thu, 14 Dec 2000 Gerhard Obrecht wrote:
> Hi,
>
> when I want to insmod my rtl-module these unresolved externals are reported:
> lseek
^
Not available in the RTL POSIXIO layer, AFAIK. (Not much point, as the layer is
meant for device I/O, rather than file access...)
> and modf). My module
From: <[EMAIL PROTECTED]>
To: "Victor Iannello" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Norm Dresner" <[EMAIL PROTECTED]>; "rtlinux mailing
list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 13, 2000 11:31 PM
Subject: Re: [rtl] Interrupt Jitter
> On Wed, Dec 13, 2000 at 04:39:32PM -0500,
Hi,
Are there any known problems using rtlinux-v3pre9 with the brand new
kernel 2.2.18.
It patched nearly with no problems (3 rejects, but no serious ones,
imho)
Greetings
Ulli
--
\ Ulli Hochholdinger E-Mail: [EMAIL PROTECTED] \
/
Thu, 14 Dec 2000 Eric Peterson wrote:
> Hi,
>
> I'm trying to use RT-Linux (2.2) RT-FIFOs, and I have come up against an
> apparent limitation with them: they only allow one writer (on the Linux
> side) to open the FIFO. I would like multiple processes to be able to
> open (a
Hi,
when I want to insmod my rtl-module these unresolved externals are reported:
lseek and modf). My module
consists of many modules which contain 'open' too which is not complained. I
havn't linked any lib.
When I link libc.a then insmod is looking for a main module etc.
My question: Which lib d
Hi Everyone,
I installed the rtl-v3pre9 distribution over my linux 2.2.16, applying
manually the kernel patch.
Some of the examples i tried seem to work fine, but i can't insmod the
psc module :
modules/psc.o: unresolved symbol pidhash
It seems that this symbol is defined in the sched.c p
Hi,
After I install the rtlinuxv2.3 on my pc,I want to test the example.But
failed.
Here is the error code.
I am looking forward your help.
Lichow
"
[root@kor hello]# make test
This is the simplest RTL program
First we remove any existing rtl-modules
You may see error warnings from "make" - ignor
21 matches
Mail list logo
