Java Compiler für AVR

[DrZoidberg]

Hallo,
ich konnte keinen Java Compiler oder Interpreter für Atmel uCs finden. Da ich gerne in Java programmiere, dachte ich daran einen Java Compiler selbst zu schreiben. Natürlich ohne die riesige API. Es wäre aber nett, wenn dieser Compiler über eine Bibliothek verfügt, die einen ähnlichen Funktionsumfang wie WINAVR bietet.

Nun würde mich interessieren, was ihr dazu meint. Wieviele Leute hier hätten gerne einen solchen Compiler oder wären auch daran interessiert einen zu schreiben?

[lekro]

Java-Compiler?
Soweit ich weiß läuft Java in erster Linie in einer Virtual Machine. Wenn man kompiliert, wäre der Vorteil der Plattformunabhängigkeit verschwunden.

Hm, da hast du dir ziemlich viel vorgenommen; bist du sicher, dass du den Aufwand nicht unterschätzt?

Ich kann nur für mich sprechen: Ich hätte vermutlich nicht so viel Interesse. Das Problem ist, dass Java-Programme eine VM benötigen. Diese VM belegt wahrscheinlich einen Großteil des Flash-Speichers. Wenn man die VM ignoriert und einen reinen (Maschinencode-)Compiler schreibt, wäre es evtl. schon eher möglich sowas zu bauen.

Bedenke aber, wie viele Leute an WinAVR mitwirkten, bis es zu dem wurde, was es jetzt ist. Ein Java-Compiler wäre mit Sicherheit nicht weniger Arbeit, eher mehr.

[voidpointer]

Es mag sein, dass Java ursprünglich für Haushaltsgeräte entwickelt wurde. Aber von diesem Ansatz hat sich die Sprache schnell entfernt. Normalerweise braucht man mindestens ein 32-Bit-System für Java.

Ich programmiere auch gern Java, aber meiner Meinung nach gehört Java nicht auf den 8-Bit-Mikrocontroller. OK, es gibt den "Javelin Stamp", der Java versteht - allerdings mit einer Menge Einschränkungen und Abweichungen vom Standard. Genauso würde es auch auf dem AVR aussehen, wenn die VM überhaupt in den Speicher passt. Am Ende wäre man trotzdem unzufrieden, weil man nicht alle Möglichkeiten der Hardware ausnutzen könnte.

Natürlich kann man einen Compiler schreiben, der Java-Syntax versteht und am Ende AVR-Maschinencode ausgibt. Aber das kostet enormen Aufwand und das Ergebnis hat nichts mit Java zu tun. Besser ist es wohl, C zu benutzen.

Achim.

[DrZoidberg]

Stimmt. Ich habe tatsächlich vor nur einen reinen Compiler zu schreiben und keine VM. Es wäre immer noch mindestens ganauso Plattform-unabhängig wie C, was für 8bit Microcontroller sicherlich ausreichend ist.
Die Plattformunabhängigkeit ist sowieso nicht der Hauptvorteil von Java.

Die grosse Java API könnte ich natürlich nicht übernehmen, lediglich ein paar grundlegende Klassen und zusätzlich einige speziell für den uC ausgelegte Klassen.

@voidpointer: Ein Compiler, der Java Syntax versteht und am Ende Maschinencode ausgibt ist doch ein Java Compiler. Wieso hat das deiner Meinung nach nichts mit Java zu tun? Solange er sich an die offizielle Spezifikation der Java Sprache hält (Java Sprache != Java VM).

Vorteile hat das schon. Zum einen bessere Unterstützung für OO Programmierung, was bei grösseren Projekten, z.B. auf einem Mega128 nützlich wäre. Damit kann man dann auch eine OO API bauen.
Event driven, sprich Interrupts, Programmierung wird auch übersichtlicher.
Genauso wie Threads. Java Threads lassen sich sicherlich über die Verwendung von Timern realisieren.
Gut - der Hauptgrund ist für mich natürlich einfach nur eine persönliche Vorliebe für Java, was aber meine Argumente nicht schwächt.

[pebisoft]

da man mit java keine schnittstellenpins einzeln (seriell,parallel) programmieren darf ( ist das oberste gebot von java), ist es von vorne rein schon nicht durchführbar , wenn es java genannt werden soll.
du entfernst dich damit von einem standart, da er keine sicherheiten mehr auf dem pc gibt.
mfg pebisoft

[voidpointer]

Ein Compiler, der Java Syntax versteht und am Ende Maschinencode ausgibt ist doch ein Java Compiler. Wieso hat das deiner Meinung nach nichts mit Java zu tun? Solange er sich an die offizielle Spezifikation der Java Sprache hält (Java Sprache != Java VM)

Der Java-Compiler (javac) erzeugt aus der Javasource einen Bytecode, den jede VM versteht. Für jede .java-Datei entsteht (mindestens) eine .class-Datei. Erst zur Laufzeit findet das Binding statt, nämlich bei der Interpretation des Bytecodes durch die VM. Dadurch bekommt Objektorientierung Sinn und wird das Konzept von Reflection erst möglich.

Auf diese und viele andere Dinge (z.B. Threads) musst Du verzichten, wenn es irgendwie in den AVR reinpassen soll. Dadurch verliert sich aber der Sinn von Java. Wie gesagt - nichts gegen einen Java-Hex-Compiler - aber es ist eine Notlösung.

Die Syntax des Javelin-Stamps ist vielleicht ein Denkansatz. Darauf aufbauend könnte man etwas für den AVR entwickeln.

Achim.

[DrZoidberg]

Der Java-Compiler (javac) erzeugt aus der Javasource einen Bytecode, den jede VM versteht. Für jede .java-Datei entsteht (mindestens) eine .class-Datei. Erst zur Laufzeit findet das Binding statt, nämlich bei der Interpretation des Bytecodes durch die VM. Dadurch bekommt Objektorientierung Sinn und wird das Konzept von Reflection erst möglich.

Wieso bekommt Objektorientierung dadurch erst Sinn? C++ Programme laufen (in der Regel) auch nicht auf einer VM. Bedeutet das, dass bei C++ OO keinen Sinn macht?

Es gibt eine Spezifikation für die Java Sprache und eine für die Java Runtime Environment. Diese beiden Spezifikationen sind unabhängig voneinander, heißen aber trotzdem beide Java. Bei C# haben beide unterschiedliche Namen. Die Sprache heißt C# und die Runtime Environment heißt .Net.
Mir geht es hier nur um die Sprache. Die RTE komplett auf einen Atmel uC zu übertragen wäre schwierig.
Man verliert dann natürlich die Vorteile einer JAVA VM, das ist für mich aber kein Problem. Auf Threads muss ich allerdings nicht verzichten. Selbst Reflections könnte man auch ohne VM realiseren. Ob das auf einem uC Sinn macht ist eine andere Frage.

da man mit java keine schnittstellenpins einzeln (seriell,parallel) programmieren darf ( ist das oberste gebot von java), ist es von vorne rein schon nicht durchführbar , wenn es java genannt werden soll.

Wie ich schon sagte sind Sprache und Runtime Environment zwei verschiedene unabhängige Dinge. Du beziehst dich auf die Java RTE, nicht auf die Sprache.

[Aldaran]

Gcc hat ein Frontend für Java ( http://gcc.gnu.org/java/). Da es auch ein Target AVR gibt, hättest du damit einen Compiler Java -> AVR Maschinencode.
Theoretisch zumindest, das Ansprechen der AVR spezifischen Hardware (UARTs, ADC usw.) müsste noch implementiert werden - weiss jetzt nicht was die Java Micro Edition dazu bietet und wie weit GCJ das wiederum unterstützt.

Trotzdem, wenn du objektorientiert auf den AVRs coden möchtest, ist C++ wohl die geschicktere Wahl, einfacher die Toolchain aufzubauen, besseres Ansprechen der Hardware, und ohne die ganze Classlib unterscheiden sich Java und C++ eh nicht besonders. Denk auch dran, dass ein im Hintergrund laufender Garbage Collector auf einem so kleinem Prozessor wie dem AVR, der üblicherweise zeitkritische Anwendungen steuern soll, sowieso nicht verwendbar ist.

Zum Implementieren von C++ auf AVR siehe auch http://www.nongnu.org/avr-libc/user-...#faq_cplusplus

Gruß, Karsten

[voidpointer]

So, habe nochmal mit einem Arbeitskollegen drüber gesprochen Man kann OO natürlich auch ohne dynamisches Binding haben. Letztlich kann man ein OO-Programm sogar in ein prozedurales transformieren. Auch gebe ich Dir recht, was den Unterschied zwischen Language- und Runtime-Spezifikation betrifft.

Dennoch bleiben viele Probleme; vor allem Resourcenverbrauch und Realtime-Verhalten. Threads schleppen üblicherweise Memory mit sich herum, das mit dem globalen Memory synchroniziert werden muss. Garbage Collection wurde auch schon als Problem genannt. Trotzdem scheint es ja mit Java Cards irgendwie zu funktionieren. Etwas Info dazu habe ich unter http://www.javaworld.com/javaworld/j...bedded-p3.html gefunden.

Aber nun das Wichtigste: Kennst Du schon simpleRTJ? Könnte das sein, was Du suchst? --> http://www.rtjcom.com/home.html

Gruß, Achim.

[DrZoidberg]

Stimmt, GCJ wäre einen Versuch wert.

SimpleRTJ sieht interessant aus, da steht aber, dass es mindestens 18kB Ram benötigt. Ausserdem ist es viel langsamer als C.