Hi, ich habe mich lange mit 8bitter und C vergnügt, nun wird es zeit sich ein neues ziel zu setzen. grundsätzliche frage macht es sinn java und arm zu kombinieren? ich habe mir zum ziel gesetzt, java zu erlernen und mich mit der thematik 32bitter auseinanderzusetzen, um java applikationen schön auf einem display(z.b.640x480 o.ä.) darzustellen. auf dem display sollen verschiedene messwerte und zustände in grafiken und in farbe angezeigt werden. es ist sicherlich ein os notwendig wie z.b. linux(µclinux) bzw. wince. oder? hat schon jemand erfahrungen mit java und µc? kann mir jemand umsteiger - tipps geben? danke javarm
Solange Java als Plattform softwaremässig übersetzt werden muss, wird es immer ein Flaschenhals in Punkto Resourcenverbrauch (Rechenleistung, Speicherkapazitäten) gebeben. Im embeddedbereich macht Java nur sehr selten Sinn, da halt mehr Hardware gebraucht wird, was den Preis für das zu entwicklende Produkt in die Höhe treibt. In der Entwicklungszeit kann java allerdings auch kosten sparen, da Javacoder in der Regel billiger sind, als erfahrene C-Programmierer.
was heißt - Solange Java als Plattform softwaremässig übersetzt werden muss - ? gibts noch andere möglichkeiten?
Java wurde ursprünglich für embedded systeme entwickelt, um sich die lästige Anpassung an ständig ändernde Hardwareumgebungen zu ersparen. So war die erste Zielplattform für Java der Bereich consumer electronics, also Videorecorder und ähnliches. Es macht also imho, vor allem bei den durchaus guten hardwarevoraussetzungen der ARMs, durchaus Sinn Java in embedded Projekten zu benutzen.
Es gibt zwei Javas: die Plattform und die Sprache. Bei dem heutigen gängigen Javalaufzeitumgebungen wird der produzierte Bytecode entweder interpretiert oder zur laufzeit compiliert. Beides verbraucht Resourcen, die für eine Embeddedlösung nur schwer tragbar. Es soll wohl irgendwann mal JavaCPUs geben, die quasi eine Laufzeitumgebung hardwaremässig implementiert haben. Bis sowas Marktreif wird, wirds wohl noch ne ganze weile dauern, denke ich.
@Mark Struber: Verstehe. Daher auch die vielen Artikel und Geräte, die alle schon seit Jahren auf Java laufen... X-)
ihr seit euch einig sehe ich ;) wie ist es den zum beispiel in einem pda oder handy oder z.b. im -game boy advance- realisiert? hier sind ja nun arm controller drin und denke auch java.
> Java wurde ursprünglich für embedded systeme entwickelt,
Und wie toll das funktioniert, sieht man bei Handys, die Prozessoren
mit weit über 100Mhz und mehrere Megabytes an RAM haben, nur damit man
darauf Java für Spiele laufen lassen kann, die auch auf dem C64 schon
gelaufen sind.
Zur Verteidigung der Javagames aufm Handy muss man sagen, das sich die Handyhersteller immernoch nicht auf eine gemeinsame GamingAPI geeinigt haben und viele immernoch ihr eigenes Süppchen kochen. Auch was die Implementierung vorhandener Javastandards angeht, verhalten sich noch lange nicht alles Handies so, wie sie sollten. Ganz katastrophal siehts da z.B. bei dem relativ neuen MIDP 2.0 aus.
also die meinungen gehen ja in sehr verschiedene richtungen. das hilft mir nun nicht wirklich weiter. was ratet ihr mir für den einstieg zu arm und einem grafik lcd display. es sollte kein monochromes sein und nicht nur 128x64 pixel haben. danke
"Und wie toll das funktioniert, sieht man bei Handys, die Prozessoren mit weit über 100Mhz und mehrere Megabytes an RAM haben, nur damit man darauf Java für Spiele laufen lassen kann, die auch auf dem C64 schon gelaufen sind." Blödsinn. Der Grund sind die rotzigen C++-Betriebssysteme wie Symbian. Wenn ich bei meinem dämlichen Nokia manchmal nach einem Tastendruck über 2 Sekunden warten muss und das bei einem ARM mit über 200MHz...
"Es soll wohl irgendwann mal JavaCPUs geben" http://www.ajile.com/ wird z.B. auf der JStamp benutzt: http://jstamp.systronix.com/jstamp_photos.htm ist aber leider etwas teuer...
es läuft wohl alles auf ein single board computer hinaus. das hier würde meinen ansprüchen ganz genügen ;) http://www.fudantech.com/cp5.asp
ich laß irgendwo, dass die arm9 sogenannte java beschleuniger haben, welcher von sun und arm gemeinsam entwicklet wurde.
@niels: gute Java Programmierer sind genauso rar und teuer wie gute C/C++ Programmierer oder Hostlinge ;) Ich sprach oben btw nur von der Sprache, die Laufzeitumgebung ist sowieso je nach hardware anzupassen. In dem Zusammenhang geht der Vergleich mit MIDP eines anderen Posters btw imho ziemlich daneben. Wenn, dann müßte man das mit CLDP oder CDP vergleichen. Die Vorteile einer Java-Umgebung wären: .) memory management! Keine Abstürze oder Fehlfunktionen durch pointer Fehler. .) Fehlerminimierung durch codereuse der zentralen Teile .) bessere Wartbarkeit durch automatisch eher Design Pattern orientierte Implementierung .) Portierbarkeit auf andere Hardware @Dominik: naja, die Firma ajile ist glaub ich der Versenkung nahe. Zumindest habe ich schon ewig nichts mehr von denen gehört...
Die Portierbarkeit des Java-Bytecode ergibt bei Mobiltelefonen, Spielekonsolen usw. durchaus Sinn, weil Programme ohne Neukompilieren auf verschiedenen Hardwareplattformen laufen können. Das geht aber nur weil eine standardisierte Schnittstelle für Grafik, Ton und I/O vorhanden ist. In den meisten Fällen von Embedded-Software (Messwerterfassung, Steuerungen) bringt die VM außer zusätzlichem Overhead rein gar nichts. Automatische Bereichsüberprüfung von Variablen, Objektorientierung und Portierbarkeit lassen sich mit zu Maschinencode kompilierten Programmiersprachen (Ada) ebenso realisieren, dazu braucht es keine VM.
> Die Vorteile einer Java-Umgebung wären: > .) memory management! Keine Abstürze oder Fehlfunktionen durch > pointer Fehler. Kann auch ein Nachteil sein. Der Memory ist zwar automatisch gemanagt, dafür aber alle anderen Ressourcen nicht. Außerdem wird das Laufzeitverhalten nichtdeterministisch, weil der GC zuschlagen kann, wann immer er gerade Lust dazu hat. > .) Fehlerminimierung durch codereuse der zentralen Teile Das ist eigentlich in jeder Sprache möglich. > .) bessere Wartbarkeit durch automatisch eher Design Pattern > orientierte Implementierung Auch das ist in jeder Sprache möglich. In C++ ist halt vielleicht ein Tick mehr Disziplin vom Programmierer gefragt, dafür wird mir hier nicht so viel aufgezwungen wie in Java. > .) Portierbarkeit auf andere Hardware Die Portierbarkeit hängt von den verfügbaren Bibliotheken ab. Da fehlt bei C++ halt einiges.
Das sind ja alles ganz gute Argumente, die für Java sprechen sollten und ich bin mir sicher, auf Hi-End-Plattformen hat das Geraffels durchaus seine Daseinsberechtigung. Ich bin nachwievor aber der Meinung, das es bis Dato keine Embeddedlösungen gibt, mit der sich kostengünstige Produkte realisieren lassen. Auch das Java in der realität, fern ab studentischer Fantastereien, nicht immer Plattforumunabhängig (portabel) funktioniert, hat J2ME (handy) längst bewiesen.
wie man auf http://www.arm.com/products/CPUs/ARM1026EJS.html sieht ist es für manche arm kein problem java aus zuführen, denn sie können das schon hardware mässig. allerdings dürfte es probleme geben einen 1026ej-s core zu bekommen und das ganze zu vernünftigen preisen in kleineren stückzahlen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.