embedded systems...

[merodeshpyarocha]

Hi,
I just want to know whether Java
a) Is as good as C/C++ for embedded and real time systems? JVM handles
the memory allocation/deallocation in Java, so does this impose any
restrictions on real time and embedded systems?
b)Has anyone ever written device drivers in Java? If so, could you
emphasize on the experience u had?
c)

 

[Chris Smith]

I just want to know whether Java
a) Is as good as C/C++ for embedded and real time systems? JVM handles
the memory allocation/deallocation in Java, so does this impose any
restrictions on real time and embedded systems?

You would certainly not use plain Java for this. There is a
specification for real-time extensions to Java, which includes (among
other things) the ability to manually allocate and de-allocate
uncollected memory. I'm not very familiar with this area, actually.

b)Has anyone ever written device drivers in Java? If so, could you
emphasize on the experience u had?

Unfortunately, the phrase "device driver" doesn't have a lot of clear
delineation of meaning. At the lowest level, you couldn't write a
device driver in Java; Java can only do computation plus those things
for which an API exists already. Step a level up, though, and you could
certainly write something that may be reasonably called a "device
driver" that sits on top of the Comm API, for example, and talks to a
specific device through a serial port. That wouldn't be very difficult
at all.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[chris]

Hi,
I just want to know whether Java
a) Is as good as C/C++ for embedded and real time systems? JVM handles
the memory allocation/deallocation in Java, so does this impose any
restrictions on real time and embedded systems?

Define "as good".

Java has a lot of good qualities, and some of them are valuable in embedded
systems, where e.g. stale pointers or memory leaks can be even more harmful
than in desktop or server systems.

If you want to do direct access to memory-mapped devices and stuff like
that, then Java is not the obvious way to do it; although the so-called
Real-Time extensions do allow you do do that.

On embedded systems you generally don't have the resources to do the things
which server-side implementations use to improve performance, so expect
things to run slower; unless you pre-compile all your Java to native code,
as can be done with gcj or Aicas' proprietary build chain. In the case of
gcj you will probably then find that the resulting binary is too big :-/
(this is being worked on).

With most implementations garbage collection leads to a level of timing
"jitter" which may or not be acceptable, depending on your real-time
requirements. Here again Aicas' toolchain can help, in that it allows you
to specify an acceptable response time and calculate the heap size (if any)
that will allow you to achieve this.

b)Has anyone ever written device drivers in Java? If so, could you
emphasize on the experience u had?

Chris Smith already answered this pretty well. I'd just add that some
"real-time" implementations do allow physical access - Aicas, NewMonics,
TimeSys come to mind.

c)

See the puff I just write for a trade show:
<http://www.kiffer.be/k/whitepaper.pdf>.