Fred,
I have had some success with signals from kernel space to user space. Have
your user mode program enable a SIGUSR1 trap/handler function and then go to
sleep. Your RT kernel module can then send a signal to SIGUSR1 each time new
data is placed in shared memory. This will in effect "sequence" your user
mode task with the RT executive.
Best Regards.
Todd Gearheart
Software Engineer Dept 041
FlightSafety
International
Simulation Systems Division
[EMAIL PROTECTED]
(316) 612-5356
-----Original Message-----
From: fred august [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 7:58 PM
To: rtl
Subject: [rtl] RT networking without RTNET
Hi,
I've been trying to do some Real time network
communications with little success. In my application
RTLinux reads sensors, sends via UDP such reading to
another machine that reads data at 1KHz, does some
computation and sends the results back to RTLinux. The
network delays should be very little (< msec) thus the
overall delay btwn when data is sent and when computed
data is received should be small (apart for lost
packets). Small delays are basic for me since the
whole thing represents a RT control loop.
I've tried this in the past with other OSs and it
worked fine. The problems I have had in this case are:
1) I can't do RT network UDP, not being kenerl
operations. I've tried to install RTNET but apparently
it is scarcely supported for RTL and didn't work for
my version of RTL.
2) I've tried with User space threads that read data
from the RT thread and do the sends and receives.
Thought it would be simple but I've had trouble,
probably due to limited experience.
First I've tried FIFOs. They would work fine until
some delay in the transmission. In that case the FIFO
would "record" that delay and would never catch up,
i.e. it would be sending old elements waiting in the
queue. I've tried to flush extra elements out with
little success.
I've used mbuff to communicate between RT and user
space thread that does the UDP send. I thought this
would solve the FIFO problems and would make more
sense in general. Unfortunately I can't control the
speed at which the user space thread sends stuff and,
if I let it poll for data to send, it will do more
than one send for each data coming from the RTL
thread, i.e. will send at a rate higher than 1KHz,
which is the rate at which the other machine receives
data. Again this has a "fill up" effect on the
connection creating a delay.
So I tried to have an attribute "new" attached to each
piece of data and have the user space thread
constantly poll this attribute until it's ready to
poll a new piece of data from RTL. In that case the
data is read from mbuff, encoded and sent, and the
attribute is set to "old" again. I thought this would
work but now the user thread is too slow.
I was wondering if there is some really obvious way to
solve this rather simple problem or not.
Would it make sense, and is it possible, to send a
soft interrupt from RTL to sleeping user threads so
that the latter can read the new data and send it via
UDP?
I'm pretty sure that if I could do sends and receives
from inside the RT Thread the problem would not
exist... but apparently I can't...
thanks for any advice
f
______________________________________________________________________
Do You Yahoo!?
Il tuo indirizzo gratis e per sempre @yahoo.it su http://mail.yahoo.it
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
