>I am dreaming about using Java with my RTLinux.
>Where can I find information about this.
>Is it hard to find out??
>Or is it better to use C/C++??
Hi Mads, I didn't find any localized repository for this information.
Rather just bits and pieces here and there. Of course this includes
the wisdom of those generous people that helped me with my querries!
Here's a diatribe :-) of my experiences. I can be more specific if
any part is of value/interest:
I structured my solution into two parts. The RTLinux side handles
all the real time issues. The Java side provides all the high
level system management and ethernet communications. It worked
very nicely. I did have some issues with speed and size. The
speed concerns had to do with the manner in which I chose to
have the communications. And the size, well, Java's libs are
quite large.
Initially the speed was a concern due to the manner in which I set
the RTLinux-Java communications. I can think of three ways to set
this up. Unfortunately my first choice ended up to be the slowest. :-)
1) Pure Java FIFO communications
2) Native Java FIFO communications
3) Shared memory
1) RTL and Java communicate directly via the FIFO. No native code
is used. Java opens a stream on the FIFO and draws data from it.
This has two gotchas. On the intel platform, the byte ordering
between the two sides is reversed. I.e. any integers passed
will have to have their bytes swapped:
private int swapBytes( int i )
{
int b1, b2, b3, b4;
b4 = ( i >> 24 ) & 0xff;
b3 = ( i >> 16 ) & 0xff;
b2 = ( i >> 8 ) & 0xff;
b1 = i & 0xff;
j = ( b1 << 24 ) + ( b2 << 16 ) + ( b3 << 8 ) + b4;
return j;
}
Note that it would be faster to do this on the C (RTL) side. I.e.
make RTL responsible for swapping bytes for all incomming and outgoing
data.
I originally chose this option so as to have a 'pure' java (no. native
code) solution. It turned out to be the slowest solution. It is also
tricky from the viewpoint of getting complete messages from one side to
the other.
A message going from RTL through a FIFO to Java can be thought of as
atomic. I.e. if you send 5 bytes from RTL into the FIFO, when Java
attempts to read them they should all be there. I say should, since
that's the way it was explained to me, but in practice I didn't always
find this to be the case. Occasionally, integers would be missing the
last byte. I ended up having to do some ugly workarounds to get this
to work, which slowed down the java side.
A message going from the Java side to the the RTL side isn't atomic.
When the RTL fifo handler is called with data in the fifo, only part
of the message can be present. So I defined a 'message packet'. The
first byte of which is the number of bytes in the packet being sent.
Thus the RTL message handler reads from the fifo, appending bytes to
the incomming message buffer, then returning. This continues until
the commplete message has been built up and can then be processed.
This worked quite well for passing commands down from the java to
the RTL side, and I continue to use it. For large amounts of data
moving from the RTL to the java side however, I abandoned this
technique.
2) Native java FIFO communications would have been a better choice. By
using a native lib, I could have taken advantage of the ioctl for
checking how much data was in the fifo, waiting to be read. This
would have made the process of extracting data much more efficient.
I didn't use this technique in the end, since choice number three
ended up being a better fit.
3) Using shared memory turned out to be the best solution for my application.
The instrument being controlled accumulates a large amount of data.
By having the RTL side accumulate this data in a large shared memory
buffer, I got the best performance. A variable is kept in the shared
memory area that indicates the amount of data currently accumulated
in the buffer.
The java side uses a native library to access this buffer. This works
well since the java side doesn't have to 'keep up' with the flow of
data as it would when it was being piped through a fifo. From the point
of view of the java side, it instructs the RTL side to begin sampling
and the data just accumulates in the buffer.
The beginning of the shared memory contains a C structure that
encapsultates
the current status of the hardware, the current amount of data accumulated,
and various other tidbits. Since the RTL side is C and the java side
is using native C code, they share the same header and everything
is quite tidy.
There is useful information on shared memory on the RTL website. The
one gotcha is the use of the vremap() + vfree() calls. But I think the
documentation has been updated by now.
This has turned out to be so much faster than using the FIFO's, that I don't
require tya to squeeze every bit of speed from the system!
The only remaining issue is of size. The class libs for java are quite
large. I can just get the kernel, deamons, class libs, C libs all in just
less then
20Mb. Of which 5-6Mb are the java class libs. It would be nice to get
things smaller, but I'm reluctant to move to C/C++ and loose the benefits
of java. I think if I spend more time I should be able to get things
smaller. I've gotten the system down to the size of a floppy in the
past, but the libs are the killers.
Hope some of this is useful.
Regards,
Jim.
--- [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/~rtlinux/
