New embedded Java-based controller released

Snijder Micro Systems just announced the public release of the second generation of their Embedded Java? Controller (EJC®) product line, codenamed EC200. The EJC is a family of embedded controllers that implement a full-fledged Java platform for network-enabled and standalone applications.

The EC200 sports a 32-bit 74 MHz ARM720T CPU and along with a slave PIC16LF872 microcontroller. The module can have up to 64 MB of SDRAM,

16 MB of NOR flash, and 256 MB of (optional) NAND flash. Integrated interfaces and onboard devices include a 10BASE-T Ethernet controller, 23 digital I/O lines, 3x 10-bit analog channels, dual 16550 class UARTs, dual fast-mode I2C master, Dallas 1-wire master, graphics LCD display i/f, an ISA-style expansion bus, etc.

The software integrates Tao Group's intent® technology, featuring an advanced Real Time Operating System and a Sun-certified Java Virtual Machine (JVM) that combines unrivalled performance with minimal footprint, due to the tight integration between kernel and JVM and to the advanced translation technology which compiles all Java bytecode to native code before execution. Java APIs are provided for efficient access to hardware resources such as I/O ports, system memory and memory-mapped devices, interrupts, and onboard peripherals. This allows developers to adopt an all-in-one approach where applications, system components, and even device drivers can be written entirely in Java, without compromising on flexibility or performance.

More details can be found in the EJC website:

formatting link

Reply to
Alberto Torrecillas
Loading thread data ...

At the risk of starting a flame war: what is the advantage of such a platform running java instead if C? I mean, java applets in a web browser I can understand. But java on a not-java controller, which has to compile in time or interpret the p-code.....


Reply to
Meindert Sprang

Java programmers are cheap and plentiful and if kept distant from the hardware don't need special training. Much like the art-school advertisements: "Anyone who can write can draw!".

Reply to
Lewin A.R.W. Edwards

Depends. Which do you prefer?

You might use Java, because it has (add a feature here, like "GC"). You might prefer C, because it has (add a feature here, like "no GC").

The device might be connected to some other system running in Java and you want to use e.g. RMI.

Or maybe you want to run same binary in several targets and want to avoid recompiling.

Or maybe you have nice development environment and want to use that.

There are millions of reasons to pick a language and avoid another.

Being interpreted/JITted might be reason to avoid, or it might not. JIT does not (necessarily) make a language that much slower or bigger to mean anything to you. Or it might.

And then there are the religious reasons ...

I have no preference, but I am happy to have choices.

Reply to
Jouko Holopainen

I guess the benefits are just the same as for desktop and server-side applications:

- Increased productivity: * Lots of good dev tools * Lots of high level APIs * Higher level language * Fully OO

- Leads to more maintainable code, less bugs.

- Portability -- can migrate to a different platform later.

- You automatically get all those nice Java things such as networking, security, remote class loading, etc. without having to do all the work yourself :)

If properly implemented, the developer should not need to care whether the platform is translating bytecode to native code before execution, as this process can be completely transparent..

Reply to

f*ck Java........

Reply to

... snip ...

Please do not toppost. Your answer belongs after, or intermixed with, the quoted material AFTER snipping those portions not germane to your reply.

Yes, you are allowed, in fact encouraged, to snip. That is one of the important points. Top posters tend to get ignored, especially in the comp.* hierarchy.

"I'm a war president.  I make decisions here in the Oval Office
 in foreign policy matters with war on my mind." -         Bush.
 Click to see the full signature
Reply to

so, CBFalconer just taught me how to post newsgroup messages............ thanks bro, i don't think i had a chance without you...............

Reply to

Has someone access to this system? I would be interested how this JIT solution on a ARM compares to a 'real' Java processor at about the same frequency. I'm actually collecting/writing testbenches for embedded Java and can provide them for a quick comparison.


---------------------------------------------- JOP - a Java Processor core for FPGAs:

formatting link

Reply to
Martin Schoeberl

Amazing how angry some people get in a discussion like this. George, calm down man :-)

My experience is that it reduces development time. We use C++ in an embedded MIPS environment (lots of RAM) and have objects to abstract hardware but also things like an IPv4Address. That may sound odd, but there really is no overhead compared to using a u_int32_t and it makes working with those data types much more convenient, which means less development time :-)

Well, yes and no. We are moving the 'core' functionality out of the product and into a library. Other tools running on the platform can use that now. So yes, there is a lot of reuse. Same way as you would reuse a libc.


Reply to
Stefan Arentz

What would you like to know?

Reply to

"Ralph.White" schrieb im Newsbeitrag news:





I would like to have some benchmarks running on this board. If you have access to the board I can send you the benchmarks or can put it on my website.


---------------------------------------------- JOP - a Java Processor core for FPGAs:

formatting link

Reply to
Martin Schoeberl




I have an evaluation kit with me. If you put the benchmarks on your site I'll have a look and send the results back.

I am also evaluating other solutions, can I have the results of your benchmarks for other systems too?


Reply to
Ralph White

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.