4 ms·

Instead of making snippy comments can someone please explain why java will not be used on embedded devices? There is big demand for java interfaces on wireless

Instead of making snippy comments can someone please explain why java will not be used on embedded devices? There is big demand for java interfaces on wireless sensor networks for instance

micheljansen 14y ago
A good start would be to have a JIT compiler so it actually runs acceptably fast: http://raspberrypi.stackexchange.com/questions/91/is-there-a-jdk-with-a-jit-compiler-available http://raspberrypi.stackexchange.com/questions/91/is-there-a...
joezydeco 14y ago
Time under the curve. Some M2M will be in higher-end devices (cars, vending machines, gas pumps) that will have lots of available power. Those will be just fine on Java or Java/Android or whatever. But a lot more devices will be running off battery power or scavenged power (solar, ambient, thermal, etc). These systems are going to wake up quickly, take a measurement or send out a message, and get back to sleep even quicker. These devices will need to consume idle power in the nanoamp range if they're going to survive their lifetime on a battery. A JVM is just not the direction these systems are taking. They're being written low-level to get the data and get out. Even reading in pages of code from NAND flash consumes way too much power to survive.
gregsq 14y ago
It's difficult enough getting many embedded engineers to go to C over assembly. In the ARM world, C is the standard for programming, but for lots of other devices, such as the MSP430, efficiency and deterministic behaviour is really important. Flash and SRAM sizes are very small in some cases and Java would simply be impossible. For bigger devices, RTOS's and C work pretty well, but you can't be liberal code wise given the amount of clocks available. And you conserve those as a necessity usually. For networked devices, where you don't care so much about power or battery drain, then I guess there's an argument to be had. NXP LPC43xx with its dual processor m4 and m0 running at 204mHz for example could just about manage it. But for devices doing work like data acquisition most designers would balk at the idea. Especially as regards memory allocation.

Instead of making snippy comments can someone please explain why java will not be used on embedded devices? There is big demand for java interfaces on wireless sensor networks for instance

micheljansen 14y ago

A good start would be to have a JIT compiler so it actually runs acceptably fast: http://raspberrypi.stackexchange.com/questions/91/is-there-a-jdk-with-a-jit-compiler-available http://raspberrypi.stackexchange.com/questions/91/is-there-a...

joezydeco 14y ago

Time under the curve. Some M2M will be in higher-end devices (cars, vending machines, gas pumps) that will have lots of available power. Those will be just fine on Java or Java/Android or whatever. But a lot more devices will be running off battery power or scavenged power (solar, ambient, thermal, etc). These systems are going to wake up quickly, take a measurement or send out a message, and get back to sleep even quicker. These devices will need to consume idle power in the nanoamp range if they're going to survive their lifetime on a battery. A JVM is just not the direction these systems are taking. They're being written low-level to get the data and get out. Even reading in pages of code from NAND flash consumes way too much power to survive.

gregsq 14y ago

It's difficult enough getting many embedded engineers to go to C over assembly. In the ARM world, C is the standard for programming, but for lots of other devices, such as the MSP430, efficiency and deterministic behaviour is really important. Flash and SRAM sizes are very small in some cases and Java would simply be impossible. For bigger devices, RTOS's and C work pretty well, but you can't be liberal code wise given the amount of clocks available. And you conserve those as a necessity usually. For networked devices, where you don't care so much about power or battery drain, then I guess there's an argument to be had. NXP LPC43xx with its dual processor m4 and m0 running at 204mHz for example could just about manage it. But for devices doing work like data acquisition most designers would balk at the idea. Especially as regards memory allocation.