Re: [Embedlets-dev] JINI SmartHome framework

[Gregg G. W. <gr...@sk...>]

>But determining what they may do best, may be a lesson in frustration (as I
>found out with the _MAXIMUM_ number of X10 modules that were "usable"),
>where a considerable amount of development time may have to be (actually
>was) trashed, just to find out "what that _CANNOT_ do best".

One of the important things it sounds like you learned is that there are in 
fact classes of problems that particular platforms are not good for.  A Java 
programming environment that supports realtime (soft or hard, or near) is much 
different from a Java programming environment that does not.  The TINI appears 
to have a lot of overhead in its JVM implementation that creates unpredictable 
behavior for certain classes of problems.  I've not had a chance to use the 
TINI that I have yet, but I keep trying to make a point to play with it.

The muvium environment and the JStamp environment have a lot more potential 
for predictable behavior it seems.  I've used the aJ100 processor via the 
PC-104 board and the dev board to develop some fairly serious applications.  
One was a remote alarm isolation multiplexor that included telnet/serial port 
management console, SNMP management and FTP file access.  The other was an 
attitude indicator that read a serial stream from an attitude indicating 
device at 19200 and drew a nice color display (like you'd see in an airplane 
cockpit) of the ground reference, bank and pitch indication.  It worked fine 
on the aJ100.  I could easily use the threading model of Java to manage both 
the data input and the drawing so that the data rate was independent of the 
rendering.

The use of the Java threading model, and monitors/semaphores make it possible 
to provide semi realtime rendering in a Java environment without realtime 
constraint support.  But, you have to learn how to always provide a consistent 
data model based on data flow in, and data use by the rest of the application.

If you have soft-realtime and non-realtime constraints that need nearly 100% 
of the CPU to be effective, then you have to learn how to segmentize those 
threads so that you provide your own quanta management within the system, 
allowing each thread to do the minimum that it needs to do to arrive at the 
next safe point.

The RTSJ efforts remove this burden from the programmer.  If more Java 
programming environment vendors provide implementations of RTSJ, then it will 
become trivial to write complicated timing-constraint based applications as 
long as the processor has enough power to satisfy the needs of the system.

-----
gr...@cy...  (Cyte Technologies Inc)