Da hat doch tatsächlich einer eine JVM geschrieben, die auf einem
ATmega8 läuft. Siehe http://www.harbaum.org/till/nanovm/

PS: Mich würde mal interessieren, wieviele bei dem Betreff dachten, ich
würde nach sowas fragen und schon antworten wollten, wie unrealistisch
das sei :-)

D. h. ich habe 512 Byte für das Userprogramm zur Verfügung.

Rolf:
"Mich würde mal interessieren, wieviele bei dem Betreff dachten, ich
würde nach sowas fragen und schon antworten wollten, wie unrealistisch
das sei"


Hier ist einer :-/
Hatte mir die Gegenargumente schon alle im Kopf zurecht gelegt, als ich
geklickt habe :)

Ich wollte nur einen Link posten, warum das Humbug ist ... (-;

Nun gut: "It is not a full Java VM, since it does not support
exceptions, threads, floating point arithmetic and various other
things" Aber immerhin. Kurz vor unfaßbar; ich ziehe meinen Hut!

Salve,

lach ja, ich muß zugeben, auch ich hatte hier einen kleinen Flamewar
erwartet, darüber, daß es überflüssig ist, auch nur einen Gedanken an
soetwas utopisches zu verschwenden... tja, hab mich wohl getäuscht. :)

Was den EEPROM als Bytecode-Quelle angeht... das sollte ja nun das
geringste Problem sein, die Routine, die ein Byte aus dem internen
EEPROM liest, durch eine zu ersetzen, die einen externen 64kx8 I²C-
oder SPI-EEPROM bedient, oder gar eine SD-Karte.

Also auch von meiner Seite aus: Respekt für so ein Projekt!

Mark

... TJA das wollte ich auch schon mal versuchen, habe dies aber nach
meinen Anfragen in diversen Foren als hoffnungslos aufgegeben.

Deshalb Respekt!

Achim

PS.: Hat damit schon jemand gespielt?

Ich habe die letzten paar Abende daran gearbeitet, das ganze in ein
benutzbares tar-Archiv zu packen. Im Prinzip müsste alles auch unter
Windows nutzbar sein (WinAVR und Java gibts dort ja auch), aber sicher
wird man ein wenig an den Makefiles drehen müssen. Ein oder zwei Abende
brauche ich wohl noch.

Aber in den nächsten Tagen werden ich alles unter GPL rauslegen, auch
die Quellen der eigentlichen VM, so dass Erweiterungen Tür und Tor
geöffnet ist. Bin mal gespannt, was draus wird :-)

Zur Zeit läuft die VM auf dem Asuro, auf einem einfachn
Atmega8-Testboad mit zwei LEDs und nativ unter Linux (prima zum
Debuggen).

Und ja, der Zugriff auf das EEPROM ist einigermassen zentral gekapselt,
es sollte sehr simpel sein, da was anderes anzusteuern, wie zum Beispiel
das Flash. Wenn man im Asuro den Mega168 nehmen würde hätte man dann 8K
fürs Java-Programm, zur Zeit mache ich das ja nur deshalb nicht, weil
im Flash nur noch sehr wenig Platz ist. Aber ein externes I2C-EEPROM
geht z.B. genauso gut. Die Ansteuerung muss halt einfach genug sein,
dass man das noch in die 8k des Mega8 bekommt.

Till

Also eigentlich hab ich ja nur nach Infos über Eclipse und ATMEGA16
gesucht, aber als Java-Fan bin ich fast sprachlos.

-
-
- !!!

Ausserdem bin ich natürlich sehr gespannt, ob das auch auf dem ATmega16
läuft. 8k Bytecode sollten dann einiges an Java-Code erlauben.

Weiterhin viel Erfolg
wünscht
Andreas

Das sollte problemlos auf dem Mega16 laufen. Die ersten Tests habe ich
damals mit dem Mega128 gemacht. Es erfordert aber ein wenig
AVR-Know-How, Routinen zu schreiben, die den Code aus dem Flash holen
(ok, das ist noch kein Kunststück), vor allem aber Routinen, mit denen
man neuen Code beim Upload im Flash ablegen kann.

Ich bin gerne bereit, dabei zu assistieren.

Till

Wow, respekt echt klasse.

wird da vielleicht auch in kleines tut folgen?

weiter so!!!

Was für ein Tutorial meinst Du? Wie man das Ding benutzt oder wie man es
erweitert? Allgemein auf AVR oder z.B. Asuro-spezifisch?

Ein paar Pläne in die Richtung habe ich, ich weiss aber noch nicht, ob
das eher ein Buch zu Asuro wird oder ein allgemeines PDF oder was auch
immer.

Till

Am besten eins über AVR und JAVA, schön strukturiert und mit beispielen
und praktischen anwendungen. Ich würds allgemein halten, basiere es
halt auf einem einfachen m16 evolution board. Am besten als frei
verfügbare PDF :)

echt stark!!!

Naja, da ich garkein Mega16-Board habe steht das nicht direkt ins Haus.
Bisher habe ich es nur auf dem Mega8 gemacht und das Flash als
Code-Speicher zu benutzen ist wie gesagt, nicht ganz trivial.

Kann gut sein, dass ich das mal mache, aber da erhoffe ich mir auch ein
wenig Mitarbeit anderer Anwender. Aber wer mir einen Mega168 für meinen
Asuro schickt erhöht die Wahrscheinlichkeit für passenden
Flash-Routinen (die dann sehr wahrscheinlich auch auf dem Mega16
laufen) ganz ungemein.

Till

schreib doch ein wikiartikel dann kan jeder mitschreiben.

Das ist eine echt gute Idee. Hast Du zufällig eine Idee, welches (ggf.
Englischsprachige, man will ja nicht alles doppelt machen) Wiki dafür
geeignet wäre?

Till

Wie wärs mit dem hier :P

http://www.mikrocontroller.net/articles/Hauptseite

:-) Das habe ich erwartet. Die Anfragen zu der NanoVM kommen zu mehr als
der Hälfte aus nicht-deutschem Raum. Darf ich hier im Wiki daher eine
snglische Seite aufmachen?

Till

http://de.wikibooks.org/wiki/Hauptseite

gibt's natürlich auch auf english

Hi

@Till
Ich kann dir auch gerne auf meinem Webspace eine Subdomain
(javaavr.matwei.de?) einrichten und ein Doku-Wiki draufwerfen. Ich hab
für Java auf dem AVR zwar keinen Einsatzzweck aber find das irgendwie
witzig und würde das Projekt damit unterstützen.

Matthias

Gratulation Till! Das Teil ist sehr sehr nett!

Allerdings ist der AVR ein wenig klein, aber da der Code relativ sauber
ist könnte man das ja auch auf einen ARM portieren, oder?

Stellt euch einmal einen LPC2103 (oder 2106) mit einem LAN-Chip und
einem MMC- oder SD- Karten Anschluß vor!
Die JavaVM ist im µC-Flash, die Java classes und Daten, logs, etc
könnten auf der Speicherkarte liegen und bei Bedarf ins RAM gelesen
werden.

Die Anwendungsmöglichkeit reichen von Haustechnik über Internet,
Kamerasteuerung, Überwachungstechnik bis hin zu professioneller
Automation.


just an idea...

Jup das fände ich auch mal gut. Da ich ja ohnehin sehr gerne mit Java
Programmiere, würde mir das sehr gefallen. Und sowas wie der aJile auf
ner JStamp ist doch sehr sehr teuer und hier in DE sowieso kaum zu
beschaffen.

Also ne JVM auf nem kleinen ARM wie eben diesen neuen LPC's von
Philips (63MIPS, 32K Flash und 8K RAM und kostet fast nix... s.
http://www.mikrocontroller.net/forum/read-1-238583.html )
... das wär schon was feines.


Ein Hausbus Projekt wäre ja gleich ne nette Anwendung dafür g ;)

http://www.mikrocontroller.net/forum/list-11-1.html



Mal schaun - aktuell hab ich leider keine Zeit das Projekt zu
unterstützen aber in ein paar wochen...

Ja, der Code ist sicher recht portabel, immerhin läuft er auch auf
Linux-PCs. Unterstützung von anderen Prozessoren selbst zu machen plane
ich erstmal nicht. Der nächste Schritt ist die Dokumentation und ein
paar weitere native Klassen für den AVR. Die nativen Klassen sind die
eigentliche Schnittstelle zur Onboard-Peripherie und für den
allgemeinen AVR (also die nicht-Asuro-Lösung) gibt es bisher nur eine
Port- und Timerklasse, damit ist nicht viel mehr machbar als eine
Modellbahnampel oder so ...

Till

Also wenn schon ein kleiner ARM, dann die neuen Atmel AT91SAM7X mit
Ethernet und CAN...

Ja gut nen AT91SAM7X ist natürlich auch was feines.

Weisst Du zufällig wie teuer die AT91SAM7X so sein werden? Also sicher
nicht so billig wie die Philips... (~2US$ @10K)

Das wäre z.B. bei sowas wie Heim Automatisierung wichtig, denn da
braucht man nicht nur einen, sondern locker mal 25 Stück oder mehr.

----------------------------------------------
Aber es sind ja alles ARM Controller - da sollte es doch ziemlich
einfach sein die JVM auf diverse Controller Varianten von verschiedenen
Herstellern zu portieren? (eigentlich muss man ja nur nen paar Adressen
vom RAM/ROM und der Peripherie anpassen)

Die Befehlssätze sind doch soweit ich das gesehen hab bei allen ARM7
identisch, oder nicht? (Habe selbst noch nichts mit ARM entwickelt,
will das demnächst aber mal antesten)

Als ich von der VM gehört hab, war ich hin und weg ;)
Vor allem, weil ich selber Linux User bin und ausnahmsweise mal nichts
anpassen muss bei so Sachen, da sie ja oft für Windows sind.

Nur bekomm ich das Tool nicht zum kompilieren, geschweige denn zum
laufen. Ich bekomm immer diese 8 Fehler:

NanoVMTool.java:36: cannot resolve symbol
symbol  : variable Version
location: class NanoVMTool
    System.out.println("NanoVMTool " + Version.version +
                                       ^
NanoVMTool.java:66: cannot resolve symbol
symbol  : variable Config
location: class NanoVMTool
    Config.load(args[curArg]);
    ^
NanoVMTool.java:70: cannot resolve symbol
symbol  : variable Config
location: class NanoVMTool
      Config.overwriteFileName(outputFileName);
      ^
NanoVMTool.java:72: cannot resolve symbol
symbol  : method setClassPath (java.lang.String)
location: class java.lang.ClassLoader
    ClassLoader.setClassPath(args[curArg+1]);
               ^
NanoVMTool.java:73: cannot resolve symbol
symbol  : method load (java.lang.String)
location: class java.lang.ClassLoader
    ClassLoader.load(args[curArg+2]);
               ^
NanoVMTool.java:76: cannot resolve symbol
symbol  : method totalClasses ()
location: class java.lang.ClassLoader
                       ClassLoader.totalClasses() + " classes");
                                  ^
NanoVMTool.java:79: cannot resolve symbol
symbol  : class UVMWriter
location: class NanoVMTool
    UVMWriter writer = new UVMWriter(writeHeader);
    ^
NanoVMTool.java:79: cannot resolve symbol
symbol  : class UVMWriter
location: class NanoVMTool
    UVMWriter writer = new UVMWriter(writeHeader);
                           ^
8 errors
make: *** [NanoVMTool.class] Error 1


Vielleicht kann mir jemand helfen.

@Andreas:

Also zum einen ist im Archiv schon ein fertiges JAR in
tool/NanoVMTool.jar, Du musst es also nicht unbedingt selbst neu
übersetzen.

Aber natürlich solltest Du es auch übersetzen können. Dazu sollte es
eigentlich reichen, nach nanovm/tool/src zu wechseln und dort make
einzugeben. Wenn das nicht klappt, dann frage bitte nochmal und
schreibe, wie Du genau die Übersetzung startest, welche Linux-Distro
mit welchem JDK Du benutzt (das sagt Dir java -version) und was sonst
noch wichtig sein könnte.

Till

Ich kann das jar auch nicht ausführen. Da bekomm ich immer ne Exception:
"Exception in thread "main" java.lang.NoClassDefFoundError:
NanoVMTool/jar"
Deswegen hab ich es ja versucht das ganze mit make zu kompilieren. Das
Makefile schriebt auch die Version in die Datei Version.java, nur der
javac bringt dann diese 8 Fehler.
Meine Distri ist Gentoo mit nem Runtime Environment in der Version
1.4.2_09

Eine englische Seite kannst du hier im Wiki natürlich gerne anlegen.

Dass Du nur ein JRE verwendest kann nicht ganz stimmen, denn bei Dir
läuft der javac ja wirklich los und versucht etwas zu übersetzen. Der
javac ist aber kein Teil der jre (re steht ja für runtime environment).
Der javac-Compiler ist üblicherweise Teil des kompletten JDK.

Bitte schreib etwas detaillierter, was Du genau versuchst. Es klingt,
als würdest Du das JAR-File mit "java NanoVMTool.jar" zu starten
versuchen. Das kann so nicht klappen, JAR-Files startet man mit "java
-jar NanoVMTool.jar".

Die Fehler, die Du beim Übersetzen hast kann ich mir gerade nicht
erklären, ich bin aber tatsächlich kein Java-Profi (ehrlich, ich weiss
mehr über die Java-Virtual-Maschine, als über die Sprache Java). Ggf.
kann jemand anderes hier auselfen.

Und wegen des Wikis: Ich habe ein neues Projekt NanoVM gestartet. Wäre
prima, wenn ihr da jeweils mitarbeitet, wenn ihr zum Beispiel Probleme
habt und dann deren Lösung findet und dokumentiert:
http://www.mikrocontroller.net/articles/NanoVM

P.S.: Hab gerde gemerkt, dass das NanoVMTool eine Exception wirft, wenn
man es ganz ohne Parameter startet. Wenn Du die "usage"-Zeile sehen
willst, dann starte es mit irgendeinem Quatsch-Parameter, z.B. java
-jar NanoVMTool.jar nase

Wenn ich es mit Paramter starte läufts.
Ja... Das JDK hab ich auch installiert. Bin grad neu in Java, weil wir
das in der Schule lernen. Alles andere kann ich aber kompilieren.

Hab bisher nur mit PHP oder C# gebastelt und das ist von Grund auf
verschieden in der Handhabung (vor allem C# (oder gleich .NET) und
Java).

Der Fall mit keinen Parametern kann in der Methode main so abgefangen
werden:

public static void main(String[] args)
{
        if(args.length == 0)
        {
                // hier die Ausgabe des Hilfetexts
        }
}

mfG,
ejd

Hallo,

ja, danke, hatte ich inzwischen gefixt. Allerdings ist eine seperate
Abfrage ja etwas unschön ... wenn schon die NanoVM kein unnötiges Byte
enthalten darf, dann verschwende ich im Tool natürlich auch keinen
Code. Daher ist der tatsächliche Patch noch etwas einfacher, als Dein
Tipp. Aber trotzdem danke!

Das ist aber noch nicht auf der Webseite. Den Fehler halte ich für so
minimal, dass ich das nicht sofort hochlade.

Till

Hallo,

nachdem das thematisch dazupasst. Die Firma domologic hat auch so eine
java-basierte GUI. Unter

http://www.jcontrol.org/

Zu kaufen gibt's die auch über ELV, da ists billiger als beim
Hersteller :)

Ich finde aber den OpenSource Ansatz ganz toll. Brint alle vorteile
mit, man ist vorallem nicht an eine HW gebunden. Wirklich genial!

Mario

Was die so "klein" nennen. Dieses JControl fällt unter die gleiche
Kathegorie wie viele andere "kleine" Java-Lösungen und benötigt
durchaus einiges an Speicher und Rechenleistung. Selbst Geräte mit dem
tausenfachen des Atmega8 (also mit 8MB Flash und 512kB RAM) fallen ja
noch unter "klein", wenn man sie mit einem PC vergleicht.

Die NanoVM läuft auf einem Prozessor, den man für Euro 2.50 bei jedem
Elektronikhändler kaufen kann. Das war mein Ziel. Mit den doch deutlich
größeren und teureren kommerziellen Lösungen wollte ich nie
konkurrieren. Aber in Kombination wird's vielleicht spassig: Die
NanoVM als billiger Sensorknoten und die JControl-Dinger als
Bediengerät, oder so.

Till

Hi,

ich habe das Wiki nun schon mit einigem an Beschreibung gefüllt. Einige
der schon hier diskutierten Fragen, wie zum Beispiel "kann ich auch ein
externes EEPROM nehmen?" und die Sache mit der Integration eigener
nativer Klassen werden dort erklärt.

Ein Kapitel zur praktischen Verwendung am Beispiel des Asuro werde ich
auch noch machen.

Das Wiki: http://www.mikrocontroller.net/articles/NanoVM

Till

Ich bekomme beim compilieren von NanoVMTool auch die folgenden fehler:

[code]
NanoVMTool.java:36: cannot resolve symbol
symbol  : variable Version
location: class NanoVMTool
    System.out.println("NanoVMTool " + Version.version +
                                       ^
NanoVMTool.java:66: cannot resolve symbol
symbol  : variable Config
location: class NanoVMTool
    Config.load(args[curArg]);
    ^
NanoVMTool.java:70: cannot resolve symbol
symbol  : variable Config
location: class NanoVMTool
      Config.overwriteFileName(outputFileName);
      ^
NanoVMTool.java:72: cannot resolve symbol
symbol  : method setClassPath (java.lang.String)
location: class java.lang.ClassLoader
    ClassLoader.setClassPath(args[curArg+1]);
               ^
NanoVMTool.java:73: cannot resolve symbol
symbol  : method load (java.lang.String)
location: class java.lang.ClassLoader
    ClassLoader.load(args[curArg+2]);
               ^
NanoVMTool.java:76: cannot resolve symbol
symbol  : method totalClasses ()
location: class java.lang.ClassLoader
                       ClassLoader.totalClasses() + " classes");
                                  ^
NanoVMTool.java:79: cannot resolve symbol
symbol  : class UVMWriter
location: class NanoVMTool
    UVMWriter writer = new UVMWriter(writeHeader);
    ^
NanoVMTool.java:79: cannot resolve symbol
symbol  : class UVMWriter
location: class NanoVMTool
    UVMWriter writer = new UVMWriter(writeHeader);
                           ^
8 errors
make: *** [NanoVMTool.class] Error 1
[/code]

Liegt das vielleicht daran, dass ich nicht die Original Sun JDK sondern
die Blackdown JDK verwende?

wenn der bootloader ersetzt wird, kann ich den avr dann eigendlich noch
normal über isp flaschen oder muss ich dann immer über seriell gehen?

Solange man es nicht über entsprechende Fuses abschaltet, funktioniert
ISP immer. Das ist unabhängig vom Bootloader.

@Blackdown:

Keine Ahnung. Aus irgendeinem Grund funktioniert bei Euch das
Übersetzen der abhängigen Klassen nicht. Kannst Du mal versuchen, z.B.
Version.java seperat zu übersetzen? Also z.B. einfach javac
Version.java einzugeben. Danach wieder versuchen, das ganze Projekt zu
übersetzen und schauen, ob der erste Fehler (der sich eben auf die
Version-Klasse bezieht) immernoch auftritt? Kann Blackdown nicht
automatisch abhängige Klassen mitübersetzen? Ich bin in der Tat kein
Java-Profi, sondern eher der C-Guru.

Und wegen des Bootloaders: Ich ersetze den Asuro Bootloader, der ist
das speziell für den Asuro vom Asuro-Hersteller in den Mega8
programmiert worden. Meine NanoVM (und deren Bootloader) werden per ISP
wie jedes andere Programm auch installiert und ersetzen dabei jedes
bereits installierte Programm, was im Falle des Asuro eben dess
Bootloader ist.

> Keine Ahnung. Aus irgendeinem Grund funktioniert bei Euch das
> Übersetzen der abhängigen Klassen nicht. Kannst Du mal versuchen,
> z.B. Version.java seperat zu übersetzen? Also z.B. einfach javac
> Version.java einzugeben. Danach wieder versuchen, das ganze Projekt
> zu übersetzen und schauen, ob der erste Fehler (der sich eben auf
> die Version-Klasse bezieht) immernoch auftritt?

Das funktionierte leider nicht, aber ich habe eine andere Möglichkeit
gefunden:

~/nanovm/tool/src$ ls ..
NanoVMTool.jar  config  readme.txt  src
~/nanovm/tool/src$ rm ../NanoVMTool.jar
~/nanovm/tool/src$ ls ..
config  readme.txt  src
~/nanovm/tool/src$ javac *.class
~/nanovm/tool/src$ make
jar cmf NanoVMTool.mf ../NanoVMTool.jar *.class
~/nanovm/tool/src$ ls ..
NanoVMTool.jar  config  readme.txt  src
~/nanovm/tool/src$

> Kann Blackdown nicht automatisch abhängige Klassen mitübersetzen?
> Ich bin in der Tat kein Java-Profi, sondern eher der C-Guru.

Ich hab keine Ahnung. Ich würde auch lieber Suns JDK nehmen, aber es
gibt davon keine 64Bit-Version.

> Und wegen des Bootloaders: Ich ersetze den Asuro Bootloader, der ist
> das speziell für den Asuro vom Asuro-Hersteller in den Mega8
> programmiert worden. Meine NanoVM (und deren Bootloader) werden per
> ISP wie jedes andere Programm auch installiert und ersetzen dabei
> jedes bereits installierte Programm, was im Falle des Asuro eben
> dess Bootloader ist.

Achso. Gut.

> ~/nanovm/tool/src$ javac *.class

Was kommt denn dabei raus? Du sagst dem Compiler im Klartext
"übersetze die Dateien, die schon da sind". Das macht m.E. garkeinen
Sinn. Der javac erwartet *.java-Dateien als Eingabe, keine Classfiles,
wie Du sie angibst. Zumindest der Sun-javac mag das auch garnicht:

> javac *.class
javac: invalid flag: AccessFlags.class
Usage: javac <options> <source files>
...

Wenn Du die vorhandenen Classfiles (also Version.class etc) da lässt,
dann übersetzt Du nichts neu, sondern baust nur daraus das JAR-File
zusammen.

Erst wenn Du das JAR-File sowie alle *.class-Dateien vorher löscht und
dann irgendwie wieder zu einem funktionierenden JAR-File kommst hast Du
wirklich das NanoVMTool neu erstellt. Wenn Du das mit der Blackdown
hinbekommst würde ich das gerne ins Makefile übernehmen.

Ciao,
  Till

@@Dominik S. Herwald (SlyD)

Der AT91SAM7X kostet bei 1000Stück abnahme um die 6€ Netto. Man muß
aber noch dazu Rechnen das man ein PHY Ethernet Chip benötigt die sind
auch nicht ganz Preiswert. Trozdem Denke ich kann man auf ca. 30€
kosten kommen für ein Embedded System ...

Gruss Sven

Hi,
ich wollte mir das grad mal näher anschauen, aber die Links zu den
Softwarepaketen auf der Seite gehen nicht. Wo finde ich denn die
Dateien?

Gruß
Markus

Ich hab mal ne Frage zur weiternetwicklung der VM!

ANgenommen ich wollte eine Lib für einen GLCD Controller schreiben (in
meinem Fall der Toshiba T6A39). Wo pack ich die am besten hin? Schreib
ich mir ne Java Klasse und füg die meinem Programm hinzu?
Oder schreib ich ne Java Klasse und füg sie der VM hinzu?
Und was is mit C Code? Brauch ich den auch noch, wenn ich der VM selber
was gutes tun will?

Andreas Galauner

Ich würd sagen schreib die Routinen am besten native in ASM oder C,
nicht in Java. Das macht das ganze kompakter und schneller.

Aber wo finde ich jetzt die Sourcepakete? Die Links auf der Seite
funktionieren nicht

"The download is currently disabled due to licensing issues. The
download will hopefully be available again soon. Stay tuned!"

Öh?
Sag blos Sun macht Stress bei deiner VM?

Ja, das steht seit gestern oder vorgestern da. Hoffentlich renkt sich
das wieder ein. Das Teil könnte nämlich interessant sein. Die einzige
Alternative die ich noch kenne wäre PyMite, und das kriegt man in
keinen Mega8

Till Harbaum(till@harbaum.org):
Guckst du hier:
http://www.mikrocontroller.net/articles/NanoVM#NanoVMTool
Er hat sich in seinem Beitrag wohl nur verschrieben...

Wird das eigendich noch weiterentwickelt?
Schön wär:
- Unterstützung für andere AVRs neben ATmega8.
- Unterstützung für Java-Bytecode im Flash.
- Konfigurierbarkeit ob Asuro mit eincompiliert wird.

Ich hab gestern mal versucht die VM auf nem Mega16 zum laufen zu
bringen. Scheint an sich auch geklappt zu haben, nur bin ich nachher
komplett durcheinander gekommen, weil ich wieder ca. 10 Konsole offen
hatte ^^

Sowas, wie ne GUI für das NanoVM Tool wär nicht schlecht, Evtl. kann
ich da ja mal was basteln, wenn ich das mit dme Swing endlich mal
gebacken bekomme. Bis wir das inner Schule machen dauerts leider noch n
bischen...

PS:
Ich hab mein Passwort vergessen, weil man das hier nich ändern kan...
Zumindest hab ich da nix zu gefunden. An wen soll ich mich da wenden?
"Passwort vergessen"-Funktion gibts hier anscheinend auch nich...

Und was ist mit "Java-Bytecode im Flash"? Hat das schon mal jemand
versucht und kann eine modifizierte Version hochladen?

Hallo,

solange die rechtliche Sache nicht geklärt ist wäre es nett, wenn
niemand irgendeine modifizierte Version hochlädt. Im  Zweifelsfall kann
sowas den Plan die Sache wieder Online zu bekommen sogar scheitern
lassen.

Die Sache dürfte sich innerhalb der nächsten drei bis vier Wochen
hoffentlich zu unseren Gunsten geregelt haben.

Till

Hi!

Woran liegt es denn genau, kannst du ein paar mehr Details posten ?
Hat sich sun beschwert deswegen ?
Interessiert mich mal ;)

Btw das Projekt finde ich super! Respekt ;)

Hi,

nein, nicht Sun, sondern mein bisheriger Arbeitgeber. Details möchte
ich im Moment lieber nicht posten.

Sorry,
  Till

Ah ok alles klar!
Dachte die sun leute haetten was dagegen gehabt ;)

Danke für die Info!

"It is not a full Java VM, since it does not support
exceptions, threads, floating point arithmetic and various other
things"

Ich hätte da mal eine Frage. Was bleibt von Java übrig, wenn man
exceptions, threads, floating point arithmetic und andere Dinge
weglässt? C oder Basic mit anderer Syntax? Was ist der Vorteil von
diesem kastrierten Java gegenüber C?

Einfach portierbarer Code...

Von einem Mikrocontroller auf den anderen.
Aber ob das sein muss weiß ich auch nicht. Weil man ja eigentlich immer
bei einem Controller bleibt bei einem Projekt.

> Ich hätte da mal eine Frage. Was bleibt von Java übrig, wenn man
> exceptions, threads, floating point arithmetic und andere Dinge
> weglässt? C oder Basic mit anderer Syntax?
Es bleibt ein kleines Java. Die Vorteile gegenüber üblichen C-Compilern
sind u.a.:

- viele Leute kennen/können eben Java und müssten C erst lernen
- Speichermanagement
- gleicher Code/gleicher Compiler (kein spezieller Cross-Compiler)
- Abstahierung der Hardware durch native Klassen (geht in C durch die
Verwednung von Bibliotheken, aber die sind bei C eben doch Teil des
Zielprogrammes und der Anwender muss sich um sie küßmmern)

Ja, natürlich ist "richtiges Java" eben auch Exceptions usw., aber
dafür reicht es im Mega8 eben nicht.

Till

für mich wären deine "vorteile" eher nachteile :/

Gibt es wirklich schon mehr Java als C/C++ Programmierer? Wenn ich mir
die newsgroups anschaue, dann hab ich eher das Gefühl, das die meisten
erst Java lernen müssten und nicht umgekehrt. Ich habe mir die JavaVM
für den AVR noch nicht angeschaut. Ich nehme mal an, dass es wie das
"richtige" Java einen garbage collector hat. Ist das nicht auch ein
Problem, wenn dieser bei der Abarbeitung des Programms einfach mal
losläuft? Ich mein, dadurch kann ich doch bei der Ausführung keine
definierten Zeiten garantieren. Oder muss man den garbage collector
explizit aufrufen?

@Till:
In welcher Sprache werden denn die native Klassen geschrieben?
Und worin liegt dabei der Vorteil gegenüber C? In C binde ich das zum
Mikrocontroller gehörende Headerfile ein, in Java das passende
Classfile. In beiden Fällen muß ich also irgendwo die CPU angeben.

Markus

Hi

es ist evtl. für jemanden der vom PC und Java kommt einfacher auf einem
µC auch Java einzusetzen. An das Einhalten irgendwelcher Zeiten die
kleiner als 1ms sind möchte ich garnicht denken. Für einen Einsteiger
schön, in dieser Kategorie an Systemleistung aber nichts für
ernsthaften Einsatz.

Deshalb:
Jede Sprache für ihren Zweck. Java macht IMHO nur da Sinn wo es auf
einen ordentlichen JIT-Compiler zurückgreifen kann. Denn Java als rein
interpretierter Bytecode ist sogar auf einem 3GHz Rechner langsam. Ich
erinnere mich mit Grauen an die erste Implementierung auf dem PC.

Matthias

Hallo,

die nativen Methoden sind in C geschrieben, wie die ganze NanoVM selbst
auch.

Ich verstehe den Hintergrund der Diskussion nicht ganz. Mit der
Einführung von Java verschwindet C doch nicht. Wer in Java nur
Nachteile hat soll natürlich weiter C programmieren, davon hält ihn
doch garkeiner ab, das mache ich selbst doch nicht anders, immerhin ist
die NanoVM in C geschrieben. Es geht doch nur um die Leute, die lieber
Java programmieren und es nun können.

Und so langsam gibt es sicher mehr Java- als C-Programmierer, frag'
doch einfach mal eine Gruppe Uni-Abgänger, was sie besser kennen und
lieber mögen. Spätestens einen Cross-C-Compiler wie WinAVR hat
praktisch niemand je verwendet. Und für Java braucht man eben keinen
neuen Compiler.

Und ja, die Garbage-Collection springt manchmal an und läuft dann eine
kaum vorherzusagende Zeit und ja, Java-Code läuft viel langsamer als C,
er wird ja durch ein C-Programm interpretiert. Aber für viele kleine
Asuro-Programme reicht es.

Die NanoVM ist einfach eine weitere Option und ihr Vorteil ist der,
dass sie nun existiert. Ihr habt nun einfach eine Wahl mehr, ob besser
oder schlechter als andere ist doch Eure Entscheidung. Ich verstehe
nicht so ganz, warum eine Java-Lösung erst dann Sinn machen soll, wenn
sie in allen Aspekten mit einer C-Lösung konkurrieren kann.

Ciao,
  Till

@Till Harbaum:

Weil Perv... Perfektionisten? ;)

Nun ja, zurueck zum Thema: Ich versuche, NanoVM auf AVR Butterfly zu
portieren, d.h. AVR Mega169. Habe ich richtig verstanden, dass der
Bootloader ueberschrieben wird?

mfG,
ejd

Die JavaVM hat sogar Vorteile gegenüber Native Compilern. Die Programme
können theoretisch beliebig groß werden wenn man ein entsprechendes
Speichermedium verwendet und man könnte noch einen schönen Debugger
implementieren der es einem ermöglicht im System ohne teure Hardware zu
debuggen. Das das allerdings schwierig wird ist mir klar, aber es ist
möglich.

Ich denke es geht hier nicht um die Sprache selbst sondern das
Grundkonzept ist ein völlig anderes (Nativ Compiler gegen Bytecode
Interpreter)

Nachtrag:

Es gibt doch auch eine Moeglichkeit, den Garbage Collector nicht
einzusetzen. Ich brauche das nicht, aber jeder der es braucht kann es
ja
programmieren...

mfG,
ejd

Hi,

ich habe keine Ahnung, welche Art Bootloader auf dem Butterdfly ist.
Aber ich programmiere den ganzen Chip neu, also wird ein ggf.
vorhandener Bootloader wohl überschrieben. Aber es hält Dich natürlich
nix davon ab, irgendwann den Originalbootloader zu installieren. Das
Problem beim Asuro ist da nur, dass man den nicht einzeln bekommt.

Und die Garbage-Collection springt nur dann an, wenn man häufig Objekte
erzeugt und zerstört. Das wiederrum geht aber ohne Garbage-Collection
auch nicht, sonst wären die 768-Bytes, die auf dem Mega8 frei sind ja
ratz-fatz voll, wenn man zum Beispiel mit Strings rummacht. Zum Bespiel
wird beim zusammenhängen zweier Strings per "+" ein neuer erzeugt und
die beiden alten freigegegen.

Till