LINUX

[hwsw famulus]

>> ARM-re van JAVA OS.
>> ARM sokszor gyorsabb mint a mega128.

> Nem. Baromi lassu a mexakitas-kezeles. Nekem siman megy masodpercenkent
> tobb 10000 mexakitas AVR-en, ARM-on nagyon behuzna a kezifeket.
> (Nem erre valo, ugy is egy masik uC csinalna a kritikus idoziteseket, amit
> nem javaban programoznank, tehat a problema nincs megoldva)
> Egyik gond, a masik hogy a Java progik garantalt reakcioideje kritikan
> aluli. A 2GHz P4-et egy assemblyben programozott barmilyen uC nagyon
> csunyan elveri.
> Tehat meg kell irni C/asm-ben az osszes drivert, periferiak kezeleset,
> a szamitasokat. Ami marad, tehat ezen komponensek sorban meghivasa, az
> mehet Java-ban, de minek?

>> Arnold
> Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/

Nos, a locsolkodast kipihenve kicsit olvasgattam az embedded JAVA temaban 
tegnap delutan....

A dolog egyetlen hatulutoje a GC (garbage collection) azaz az automatikus 
memeoria felszabaditas,
ami ugye a JAVA KOTELZO resze....es legnagyobb ELONYE.

Ez lenyegeben ket mododn oldhato meg:
- a tobbi processzhez addig off-line, tehat megall az elet szamukra
 ez az ut a real-time vilagban nyilvan nem jarhato
- a tobbi proceszhez kepest kisebb prioritasu hatter processzben
 ekkor megno a memoria igeny es jelentos szamitasi teljesitmenyt visz el
Ami azt jelenti, hogy algoritmustol 25 szorosig terjed a lassulas.
Ami latszik, hoyga JVM igenis gyorsabb a GCC-nel pl.....

ATmega128 eseten (kulso RAM-al szerelve) 4 MHz!!!! orajel esetn vizsgalva.
(A cuccos JVM kiepitestol fuggoen 61-89 K flash-t es <32 K RAM-ot ker.)

Kulonbozo teszt progik eseten az alabbi aranyokat hozta ki:

GCC   100%
GCJava  202%
SUN JVM  90% !!!!!!
RealJAVA no GC  209% (ez meg elmegy..)
RealJAVA with GC  2470%  :-(((

RealJAVA eseten
az interrupt  latency 2-14 uS,
response time 27-43 uS
a task valtas interruptban worstcase 963+358*taskokszama orajel
a task valtas normal worstcase 740+12*taskokszama orajel
mutex kezeles 1024+12*taskokszama orajel
objektum letrehozas 234+78*i+54*n orajel
100 uS thread timing eseten a workload ~ 30 uS
(tehat 10 Khz meg megy azert...)

Nos, nagyjabol igy all a manapsag a dolog technikailag embeddedJAVA ugyben
A nem ilyen  aprocska 4MHz-es ATMega128 eseten, nyilvan javul a helyzet...
.
Elonynek tartjak a teljes programozoi szintiu compatibilatast
a konnyu kapcsolodast mas eszkozokhoz TCP/IP alapon.
A szabvanyos file kezelest, a pointermentes adatkezelest
a szigoru tipusossagot, szoval a
programozoi hibaelkovetes minimalizaltsagat.

Hatranynak  a GC miatti nagy overhead-t.

A JVM-t egyebkent ASM betetes C-ben irtak

Meglatasom szerint, olyan feladatok eseten amik nem igenyelnek
extra gyors reakciot, viszont komplexek ill.
komolyabb userinterface kivannak igenis hasznalhato lesz.
Ha hozzafer majd a foldi halando is....mert
letolthetot nem talaltam a fel nap alatt sehol.

KJ