Zitieren
Ich kann mich da meinen Vorrednern nur anschliessen. Java auf nem AVR halte ich nicht für sonderlich angebracht. Erstmal musst du die Sprache gründlich abspecken: Serialisierung, Security, RMI, AWT, Reflection API, und so fliegt raus. Nebenläufigkeit wohl auch. Einen Großteil der Leistung opferst du für die VM, an Flash, RAM und EEPROM. Java sieht es nicht vor, direkt auf die Hardware zu greifen, also brauchst du native Klassen um auf SFRs zu greifen und das zu erledigen, also für jedes Derivat ne neue API.
Bytecode ist zwar recht kompakt, aber mit 1-2 kBytes wirst du auch nicht sooo weit kommen, dazu bei grottiger Performance. Auf einem Hostrechner spielt das keine Rolle, da ist es viel wichtiger flott entwickeln zu können und Abstand von der Hardware zu haben (meistens jedenfalls), und da verwende ich Java wo ich kann.
Teile deines AVRs wirst du aufgrund der langsamen Abarbeitung gar nicht nutzen können, bei InputCapture oder hoher Interrupt-Last wird's jedenfalls sehr schwer. Bei Systemen an der Grenze gehen die Kosten immens in die höhe: Entwicklungszeit, Stabilität, Nerven, so daß du nicht wirklich was sparst.
Dem RAM geht fix die Luft aus: die VM belegt einen Großteil und int in Java ist 32 Bit breit. Weiterhin ist die Frage, ob die VM dafür ausgelegt ist, Flash zu nutzen, zB für Tabellen. Falls nicht, belegen die auch Platz im RAM (oder im EEPROM). Und was nutzt dir Java, wenn der Code für ne Hashtable dein ganzes EEPROM auffrisst?
Portierbar dürfte das Zeug auch nicht sein. Der Bytecode für einen Mega8 wird auf einem Mega128 nicht funktionieren.
Mit avr-gcc hast du einen Leistungsfähigen C-Compiler für die AVRs, ausser für ein paar Winzlinge. Die C-Syntax ist dir offenbar vertraut. IMHO ist es weniger Aufwand, dich mit C anzufreunden, als dir den Wolf nach ner VM zu suchen. Scheint ohnehin eher eine mentale Hürde zu sein...
Lesezeichen