Yes Java will proaly never be suitable for the majority of real-time
embedded systems, but it still has a place. Just like C is less effective in
a real time environment (still have to write low level stuff in ASM) it
certainly has a place and for some tasks it is almost as efficient as hand
coded ASM (not taking into account competency of the programmer which will
always be the major problem). Likewise Java has a place, not for real-time
embedded systems but for embedded systems performing more complex, less time
critical tasks.

Not sure which tiny Java you're talking about. Sun (and others) have
published specs for Real-Time Java (JSR-001) which deals to some extent with
the shortcomings of Java for real time systems. For instance:
- Garbage Collection now allows different implementations and is more
tailored to real time design. So you can have synchronous (or I believe
manual) garbage collection if you wish. Also asynchronous (mark and collect)
collection is supposed to be more deterministic.

Thread scheduling has also been improved vastly. As with GC it suports
multiple implementations. For example, one can create cyclic (or acyclic)
tasks and do some pre-runtime scheduling.

And a primary aim is more determinism. Obviously it will never be suitable
for all tasks, but it has it's place. Devices such as PDA's, Mobile Phones,
Wearable Computers, Embedded Web\Database Servers will start to make
increasing use of high level languages such as Java due to the comlexity of
current products and short development cycles neccesary.

Tom.
-----Original Message-----
From: Robert Swirsky-Warner
To: PICLIST@MITVMA.MIT.EDU
Sent: 2/03/01 2:38
Subject: [PIC]: Java PICmicro MCU Development Tools

Java is a rotten language for embedded programming (and nearly
everything else, too! We all dislike it here, and use it when we
absolutely have to).

A compliant Java VM would be very large, and would consume vast
amounts of RAM: memory is allocated and freed automatically
by its "garbage collector"--not a good choice when you only have
a precious 47 bytes of memory! I know Sun is working on "tiny"
version of this, but even those would be a minimum of several
hundred K for the exeuctable code itself.

Also, since you never know when it will decide to clean up
its memory, it makes it difficult to do real-time applications
where something must be guaranteed to happen within a predictable
time period.

A long time ago, Forth (it's spelled that way!) was popular
for embedded work. It runs on 8051s and PICs, and just about
everything else, too: http://www.forth.org/compilers.html
You may want to take a look at Forth if you want a HLL!

--
Robert Swirsky-Warner
Walt Disney Imagineering, R&D

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body