Druckbare Version
Hallo,
bevor ich meinen Asuro zusammenbaue und anfange, C zu lernen, habe ich eine Frage bezüglich Asuro und Java:
Gibt es eine Möglichkeit, auch durch evtl. Microcontrollertausch, den Asuro mit Java zu programmieren? Da ich gerade Java lerne, würde mir dies sehr gut reinlaufen!
Bin gespannt, welche Antworten kommen.
Schönen Abend wünscht
Daniel
Hi nokri,
diese Frage hatten wir hier schon einmal. Java hat ein Problem direkt auf Hardware zuzugreifen.
Dieses Problem kann man mit eigenen Routinen umgehen. Das hätte jedoch zur Folge, das man sich so weit von den Java - Spezifikationen entfernen muß, das man kein Java mehr hat.
Dies ist jetzt mehr nachgeplappert, da ich Java nur auf meiner HP benutze. Versuch doch mal über die Suchfunktion den Thread zu finden. Dann erfährst Du mehr darüber.
Gruß Klaus
edit :
hab selbst mal unter dem Stichwort 'Java' gesucht
https://www.roboternetz.de/phpBB2/ze...ag.php?t=10276
https://www.roboternetz.de/phpBB2/ze...ag.php?t=10029
Genau die Frage habe ich mir auch gestellt und vor ein paar Wochen auch gleich die Lösung gebaut. Das mit der Plattformunabhängigkeit stimmt natürlich: Code der für den Asuro geschrieben ist läuft zunächst nicht auf einem PC. Allerdings hält Dich keiner davon ab, meine Asuro-Klassen auch auf dem PC mit Leben zu füllen. Das gleiche Programm, das den Asuro fahren lässt könnte dann auf dem PC einen animierten Roboter über den Bildschirm steuern.
Ich habe erste Sachen unter www.harbaum.org/till/nanovm online gestellt. Zur Zeit ist das noch nicht vollständig, aber in den nächsten Tagen sollte das alles kommen, was man zum Betrieb des Asuro unter Java braucht.
Till
Hallo,
ich bevorzuge für die Asuro-Programmierung auch C, aber ich fand den Link:
http://www.mikrocontroller.net/articles/NanoVM
und darin ein Beispiel:
http://www.mikrocontroller.net/artic...AsuroLine.java
Hat sich bzgl. Asuro und Java in der Zwischenzeit was getan?
Ja, der Asuro wird voll unterstützt. Der ist sogar eher unter "altes Eisen" einzuorden, denn in letzter Zeit ist der c't-Bot dazugekommen.Zitat:
Zitat von HermannSW
Beide sind mit entsprechenden Klassen versorgt und die üblichen Anwendungen wie Linienfolger etc. lassen sich prima in Java lösen.
Hi,
da stellen sich mir gleich 3 Fragen:Zitat:
Zitat von Harbaum
- die Warum-Frage:
Warum Java auf dem Asuro?- die Kosten-Frage:
Was kostet ein Java-Programm im Vergleich zu einem entsprechenden C-Programm auf dem Asuro (space/performance)?- die Macht-Frage:
Wer macht's, d.h. wer entwickelt mit Java auf dem Asuro?
[Alle Code-Stücke, die ich bisher (bis auf den obigen Link) gesehen habe, waren in C geschrieben ...]
Tja...
Warum: einfach weil es funktioniert. Und wer mit java gut umgehen kann, kann so etwas rumprobieren. Warum wird der Mount Everest bestiegen? einfach weil es möglich ist. Also in erster linie for fun, denk ich mal.
Kosten: Tja... die NanoVM muss aufgespielt werden, und die braucht schon etwas speicher... und da nicht nur die befehle ausgeführt werden müssen, sondern diese durch die VM interpretiert werden und dann ausgeführt (dazu muss das programm im klartext vorliegen, nicht in maschinencode... das braucht auch speicher) denk ich mal dass man performacetechnisch mit C oder asm oder bascom usw besser dran ist.
Wer Machts: Keine ahnung. Ich habe mich nicht genug mit java beschäftigt um es probieren zu wollen =)
Jetzt mal ehrlich: Warum erwartet jemand, der einen Asuro benutzt, dass die darauf zu verwendende Sprache irgendeinem Anspruch genügt, der über "weil's geht" oder "weil's Spass macht" hinausgeht?Zitat:
Zitat von HermannSW
Der Asuro ist für keine einzige echte Anwendung geeignet und stellt puren Selbstzweck dar. Alle Argumente, warum jemand ein Gerät wie den Asuro kauft, selbst zusammenlötet und dann Kreise auf dem Küchentisch drehen lässt beantworten genauso Deine obigen Fragen zur NanoVM.
Mögliche Antworten:
- um etwas zu lernen
- weil es Spass macht
- weil es eine Herausforderung ist
- weil das Vorbild zu komplex ist, um mal hinter die Kulissen zu schauen
- weil man Leuten damit etwas beibringen kann
...
Hallo Till,
soweit ich gesehen habe, hast Du die JAVA-Engine geschrieben, Hut ab, super Leistung. Ich denke mal, das haben die Vorposter nicht ganz begriffen.
Was ich mich frage: Warum nicht einfach den Atmega8 durch einen Atmega168 ersetzen, der hat doppelt so viel Flash und passt soweit ich weiss von der Pinbelegeung. Mit dem Prozessor hätte man den doppelten Speicher, dann dürfte auch für Java etwas mehr Luft sein, oder?
Gruss,
stochri
Hallo,
entschuldige, wenn meine Fragen negativ rübergekommen sind -- das war nicht so gemeint, und vielleicht hätte ich auf die Warum-Frage verzichten sollen.Zitat:
Zitat von Harbaum
Insbesondere die Kosten-Frage war aber ernst gemeint. Was kosten vergleichbare Programme in C und Java an Speicherplatz (bei 7KB verfügbar eine berechtigte Frage, finde ich).
Und dann natürlich auch noch die Performance von Java versus C, obwohl das wohl eher unkritisch ist (ich habe bei meinem Linienfolger gemessen, daß die Haupt-While-Schleife in ca. 8 Sekunden mehr als 10000 mal durchlaufen wird -- da bleibt genug Platz für ein bißchen zeitlichen Overhead).
Ganz am Anfang von Java (ohne die Just-In-Time-Compiler) gab es mal eine Fastregel auf dem PC, daß die Laufzeit ca. doppelt so hoch ist wie bei C. Ich habe jetzt noch nicht in Deine nanoVm reingeschaut, kann die Just-In-Time-Compiling?
... aber auch für eine Menge an Spaß! :)Zitat:
Der Asuro ist für keine einzige echte Anwendung geeignet und stellt puren Selbstzweck dar.
Das hatte ich sehr wohl begriffen (ich habe ja oben die beiden Links reingestellt, und der Autor der Beträge war ja Till), ab da sich in diesem Thread seit 2005 nichts mehr getan hatte, wollte ich nur mal nachfragen ...Zitat:
Zitat von stochri
Warum wird eigentlich immer behauptet; java sei langsam?
Langsam ist nicht eine Sprache, sondern bestenfalls der erzeugte Code bzw. die Tatsache, daß Java idR nicht nativ läuft, sondern der Bytecode durch eine VM interpretiert wird.
Nirgwndwo steht geschrieben, daß Java in Bytecode vorliegen muss. Ebenso gut ist es möglich, Java-Programme direkt in ausführbaren Code zu übersetzen, also in Code, der nicht für die Maschine JavaVM codiert, sondern zB für einen AVR.
Die Plattformunabhängigkeit geht dabei verloren, aber auf einem System wie AVR hätte man die eh nicht. ZB hat nicht jeder AVR einen PortA oder einen LCD-Controller.
Daß Java (und auch Bytecode) nach Object-Code übersetzt werden kann, zeigt GCC.
GCC unterstützt standardmässig mehrere Sprachen: C, C++, Java, Ada, Fortran, Objective C, C#, irgendwann vielleicht D, ...
GCC unterstützt zudem viele Prozessoren/Controller, u.a. bekanntlich AVR und nennt sich dann avr-gcc.
Eigentlich ist es doch naheliegend, auch mal zu sondieren, inwieweit die bestehenden GCC-Teile "Sprache" (Frontend) und "Maschine" (backend) zusammengebracht weden können.
Der große Haken beim nativen Übersetzen von Java ist hier die libjava, welche die Unterstützung für das Zeug wie java.io.*, java.awt.*, Threads, Serialisierung, RMI, Reflection, etc enthält. Die Arbeit würde also darin bestehen, einen ausgesuchten Teil der libjava-Quellen mit avr-gcc zu übersetzen zu einer libavrjava oder so, die dann gegen die aus den Java-Quellen erzeugten Objekte gelinkt werden könnte, um eine ausführbare Datei zu erhalten.
Die Erweiterungen im Compiler selbst dürften nicht allzu groß sein; standard-Hooks für zB Exceptions und unrolling der eh-frames sind ja vorhanden. Evtl ist es auch möglich, auf exception zu verzichten, wie avr-gcc es bei C++ macht. Zudem ist die AVR-Maschinenbeschreibung im GCC praktisch unabhängig vom der Sprache und bereits vorhanden (anders wäre es unmöglich, so viele Kombinationen von Programmiesprachen und Controllern in GCC zu unterstutzen).
Auf Ebene der binutils (Assembler, Linker) wäre noch weniger bis garnix zu tun, evtl würden neue Linkerscripte schon reichen.