I haven't
Nikolay Ognyanov wrote:
> 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/
>
> --- [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/
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
