Hi James,
Could you please tell us a bit more about your project? The problem
of putting RT Linux into FLASH has been raised several times on
this list but as far as I can recall you are the first one to present a
real case study. Could you tell more about this : what kind of FLASH
device you use, did you have problems with making Linux boot from
it etc.? Also did you try to reduce in some way Java footprint ? How
big your instalation (including Java) is?
BTW, does somebody know about Embedded Java more than can be
found on JavaSoft site? Could it have something to do with RT Linux?
Regards
Nikolay Ognyanov
James Cassidy wrote:
> At 08:38 AM 11/24/98 -0600, Wright, Robert B. wrote:
> >I would also like to hear about any projects that incorporate java and rtl.
>
> Ok, please excuse me if this is a bit long winded.... :-)
>
> I'm currently working on two projects that involve RTLinux and Java.
> Both involve real time instrument control. One is more deeply embedded
> than the other. I.e. no monitor, keyboard, just an Ethernet connection.
> The other actually has a GUI component but is being designed such
> that the GUI component doesn't have to reside on the instrument doing the
> acquisition.
>
> Both designs use RTLinux and C to handle all the hard real time instrument
> control as well as the acquisition. Several FIFOs connect this real time
> layer with the Java code. One FIFO is for commands, one for responses,
> one for the acquisition data stream. One FIFO is used for error propegation
> from the real time layer up to the GUI layer.
>
> Some fiddling is required to get Java to read data from the FIFO properly.
> First, the byte order must be switched. Secondly, I found that, on occasion,
> simply trying to read four bytes from the fifo wouldn't work properly. So
> I had to counteract with a rather ugly kludge.
>
> I've found that connecting the real time layer and the non-real time Java
> layer in this way isn't very efficient for moving large amounts of data.
> I'm currently exploring another possibility to improve performance.
>
> Both designs use a PC104 interface board that I've designed and built to
> offload
> some of the processing overhead. A programmable timer on the board starts
> a conversion. When the conversion finishes, an interrupt is generated. The
> ISR (in the real time layer) reads the value, passes it to the data FIFO and
> switches to the next channel to be serviced.
>
> Both designs boot a pared down RTLinux system from an IDE flash disk. They
> run from memory so the systems can be powered down without concern for
> any shutdown.
>
> Both are running from an Advantech single board computer measuring about
> 4"x6".
> These SBCs contain ethernet, video, IDE controller, etc. So the overall
> system is quite compact.
>
> Overall, I'm quite impressed with the combination of RTLinux and Java. This
> instrument needed to be networked. Using Java, I was able to jam in more
> than was required in the tight timeline that was available. I've done similar
> things in C, C++ and strongly believe that it was quicker & simpler to do
> in Java.
> Primary to this belief was a) the networking classes, and b) multi-threading.
> Granted, it's not as fast as had it been written in C or C++. But I'd
> probably
> still be writing it had it not been for Java.
>
> Originally, one of the projects was started in QNX, but was switched to
> RTLinux
> after a period of evaluation.
>
> The instrument currently can handle multiple clients. Only one of which can
> control the instrument. The others being only to interrogate the instrument
> for things like: current instrument status, time remaining on current job,
> current owner, etc.
>
> Also, it was easy to build debugging into the design. Multiple concurrent
> debug monitors can attach to the instrument via the network and receive
> information on the current operation of the program, as well as thrown
> exceptions and stack traces are reported to any debug monitor programs
> that might be attached. So if a customer calls and says that the instrument
> fails randomly once a week, I can attach via the net and monitor for that
> intermittent failure.
>
> One unit has been tested for a while in another department. When I asked
> about any crashes or failures of the RTLinux system, all I got was blank
> stares. It has never happened.
>
> Also, I can update the software and reboot via the net. When they ask
> for a change, I do the update, then phone them and ask what version
> number is reported on the instrument's LCD panel to confirm the update.
>
> They find this quite amusing. I find it very convenient, as I'm about
> 100km from where it's being tested.
>
> Hope this was of some interest.
>
> 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/
