Einige werden mich jetzt wahrscheinlich als Idiot, Wahnsinniger usw klassifizieren. Reine Theorie : Besteht denn nicht die möglichkeit eine Java VM auf der AVR zu haben ? Anstelle des Maschinencodes packt man halt das Java Byte-code auf ne SD Card und lässt es von der VM Interpretieren. Ok, die Nachteile liegen auf der Hand ( Perfomance ) aber ich sehe auch vorteile. Dann dann könnte man ja OOP programme schreiben die wunderbar strukturiert wären. Gibt es denn so ein Project von den ihr eventuell berichten könntet, denn ich habe fast nichts im Rindernet gefunden. mirki
ja, das ist bekloppt. wenn du unbedingt oop haben willst benutz avrgcc für c++, dann sinkt zwar immer noch die performance aber immerhin sitzt nicht noch ein interpreter dazwischen. das ganze speichermässig zu schaffen dürfte interessant sein. ausserdem gibts fertige uC mit java vm...
Ne, so verrückt ist das nicht. Z.B. gibt es von Maxim ein 8051-Board mit Java: http://www.maxim.de/quick_view2.cfm/qv_pk/3743 Da es das schon einige Jahre gibt, gibt es bestimmt auch ein Forum dazu, wo man näheres erfährt. Das es ein 8051 ist und kein AVR könnte daran liegen, daß dieses 8051 Derivat bis 16MB externen Codespace unterstützt. Peter
Hallo Mirki, DU Wahnsinniger. Ich gehöre auch zu dieser Gruppe die darüber nachgedacht haben. Willkommen im Wahnsinnskreis. Spaß bei Seite. Beim Atmel scheitert es an den Resourcen. Insbesondere am benötigten RAM. Die neuen Handys (z.B.: NOKIA mit MIDP 2.0) haben mächtig was drin und haben auch einen breiteren Prozessor (16/32 Bit?). Den SourceCode der J2ME VM kann mann ja downloaden und das portieren müßte mit einigem Aufwand auch gehen. Aber der Ram ist wirklich zu klein, selbst für die Mindestanforderungen. Ich versuche eine HybridVersion zu bauen. Fernziel: NANO-PC Board mit Standard Java und die "transparente" Einbindung von Atmel_Satelliten zur Datenerfassung. Kommunikation zunächst über die ser. Schnittstelle, später über Ethernet (MODBUS,PPP,HTTP,SOAP, WEBSERVICE..). Das Atmel-System macht das Notwendigste und was es gut kann. Das JAVA-PC-System den Rest. So ähnlich wie das oben erwähnte Dallas System nur eben verteilt und Standard Java. Somit entfällt die eigene (eingeschränkte)JAVA Portierung. Ziel: Transparente Einbindung von Externer-Hardware an ein "Volwertiges-Standard-Java". Irgendo gibt es da ein Project, welches auf ein NANO-Board ein Standard-Java-System implementieren möchte welches unter Linux läuft. Dortiges Ziel Opensource==>auspacken==nach ner 1/4 Stunde Läuft die Java-Umgebung ohne was mit Linux im Hut zu haben. Das in verbindung mit nem Atmel wäre gar nicht so schlecht. Werden die Mikros mächtiger (was zweifelsfrei der fall ist) portiert man auf diese immer mehr Funktionalität. Ich weiß jetzt kommen die JAVA Gegner wieder auf die Matte, aber die ganzen Librarys mit dessen Funktionalität, EntwicklungsTools etc. und das Ganze kostenlos... Welchen Programmcode kann man leichter zwischen den verschiedenen Welten portieren...? Natürlich eine "gehende" VM als Basis... Falls da ein FanClub zusmmen kommt... Ich bin dabei. Viele Grüße Achim
Lasst uns mal das Speicher-Problem als ersten ansatzpunkt betrachten : 1. Hardwareseitig kann man ja max. 64kb adressieren. 2. Um mehr speicher haben zu können muss man ja lediglich das ganze Softwareseitig adressieren. 3. Mann könnte doch einen Bootloader haben der die VM aus einer SD-Karte läd. 4. Da jetzt fast keine I/O's mehr vorhanden sind, könnte man doch die Peripherie an einen I2C hängen. Ist das falsch was oben steht ? mirki
am AVR ja ;) also 128KB sollten doch reichen für eine javaVM... gui usw hat man nicht...also sollte sich meiner meinung nach das locker ausgehn... also VM in den flash vom AVR und den code der ausgeführt wird auf die SD card.... ram... DRAM dran... dürfte kein prob sein da die refeshes zu timen... und soo schnell ist man so oder so nicht.... anderseits...forth ist angeblich besser brauchbar... nur gefällt mir da die sprache so seltsam g 73 de oe6jwf
Hallo wie ich sagte, der Speicher ist das größte Problem. Desweiteren muß man bei einer derartigen Portierung immer Einschränkungen machen. Das sieht man bei allen Embedded Java Systemen. Leider haben sich diese Systeme nicht weit verbreitet. Ich hatte da in den letzten Jahren mehr erwartet. Ferner muß man diese Portierung immer wiede neu anpassen. Deshalb verfolge ich derzeit das Ziel eine "kostengünstige" Standard Hardware mit einer "vollen" SUN-JVM zu nutzen und übers Netzwerk,ser. Schnittstel,I2C, USB meine HArdware u.a. Atmega's transparent einzubinden. Falls dieser Bereich wächst kann mann ja immer mehr Funktionalität auf die Atmegas bringen, vielleicht auch mal Java. Derzeit ist das - glaube ich- ohne hohen Zeitaufwand nicht möglich. Ich habe mich von diesem Gedanken verabschiedet, behalte in jedoch im Hinterkopf und verfolge die technische Entwicklung. Viele Grüße Achim
Es wäre schon ziemlich cool eine abgespeckte VM auf die AVR zu portieren. Meine Intension geht mehr in Richtung KI @ admin : mach mal ne neue rubik für wahnsinnige auf !!
>Es wäre schon ziemlich cool eine abgespeckte VM auf die AVR zu >portieren. was ganz schlankes wäre waba... keine ahnung ob es vom umfang her deinen ansprüchen genügt. http://www.wabasoft.com/products.shtml
Eine Möglichkeit wäre ein Java nach C Converter, der aus Java Code C Code macht, der dann vom AVRGCC compiliert werden kann. So etwas habe ich schon für den Texas Instruments Taschenrechner TI89 gesehen aber leider kenne ich keinen für uCs. Man könnte naürlich einen schreiben. Da hätte man dann auch keine Probleme mit der Performance, da der Code ja compiliert wird. Es läuft also keine VM auf dem uC. Es wäre dann also genauso schnell und speicherlastig wie ein C++ Programm, das mit avrgcc compiliert wird.
Naja, ich weiss nicht. So ein knoverter würde m.E. nach mehr müll erzeugen und noch langsamere programme erzeugen. Es geht mir nicht darum in Java zu coden nur weil ich das so geil finde. Ich will einige vorzüge von Java nutzen was C++ nicht von haus aus selbst kann, und es soll auch von der VM interpretiert werden.
> Ich will einige vorzüge von Java nutzen was C++ nicht von haus
aus selbst kann
Welche?
ich wusste das diese frage kommt. Und auch ehrlich gesagt habe ich auch mit Dir gerechnet. OK, eins fällt mir gleich sofort ein. Objekte in Java werden bei nicht Nutzung ins Nevada geschossen, bei C++ muss man sich selber drum kümmern. - Garbage-Collection Aber dennoch muss ich sagen das Software in Java zu entwickeln ist alles andere als leicht, es ist lediglich einfacher als C.
Wieso? Mit einem solchen Konverter könnte man alle Vorzüge von Java nutzen. Auch Garbage Collection. Etwas langsamer als ein in C geschriebenes Programm wäre es natürlich, aber wenn man eine VM benutzt wird es doch noch viel langsamer.
@mirki wo wären denn die vorteile einer vm bei uC? absicherung ala sandbox kann es ja nicht wirklich sein
>Dann dann könnte man ja OOP programme >schreiben die wunderbar strukturiert wären. hat man dir nicht erklärt dass man OOP auch ohne OOP Sprache schreiben kann ? Genauso wie man strukturiert programmieren kann ohne eine Sprache zu benutzen die das speziell unterstützt. Vor allem haben viele OOP Programme eine fürchterliche Struktur weil das klar strukturierte Denken durch ziemlich konfuse Benutzung von Objekten ausgehebelt werden kann.
> Vor allem haben viele OOP Programme eine fürchterliche > Struktur weil das klar strukturierte Denken durch ziemlich > konfuse Benutzung von Objekten ausgehebelt werden kann. ist das dann a) die schuld des OOP paradigmas b) die schuld einer sprache die OOP speziell unterstützt c) die schuld das programmierers ?
nee so wahnsinnig bist du nicht denn darüber habe ich auch nachgedacht :-) Und es gibt ja schon die kleinen Steuerungsrechenr die mit Java laufen allerdings haben die meisten wirklich mehr CPU Power wie ein AVR z.b Snap oder Jcontrol um mal etwas abzuschweifen - ich fände schon eine alternative Hochsprache für AVRs sinnvoll - warum nicht pascal?
@ Thomas ich erlaube mir einen Punkt hinzu zu fügen : d) bei Java hat Smalltalk alles versaut. @ Gerd Ja, du hast recht. Aber OOzuP ohne eine OOP ist die Hölle !?! Naja, meiner erste richtige sprache war Pascal, dann kam der Umstieg auf Java, und das viel mir sehr schwer wegen diesen s.... Objekten. Jemand der zum erstenmal programmieren lernt und dafür Java nimmt, erlernt dies viel schneller. Bevor man eine OOP sprache lernen will, sollte man OOP lernen ?! hmmm, I LOVE PASCAL !!!
Auf dem Amiga gab es sogar einen Objekt orientierten Assembler ich hab mich nie damit beschäftigt weiß also nicht ob er alle Aspekte einer OO Sprache berücksichtigt (glaub ich auch nicht) aber das tut Java ja auch nicht. Die Anhänger der OO streiten sich heute noch darüber was sinnvoll ist und sein muss und was nicht zu OO gehöhrt und nur alles verschlimmert. So ähnlich wie der Streit der strukturierten Sprachen Anhänger über das 'Goto'
>Ja, du hast recht. Aber OOzuP ohne eine OOP ist die Hölle !?!
Nein ich meine eher OO mit OO-Sprachen kann die Hölle sein.
OO-Sprachen geben einem die Möglichkeit 'versteckte' Funktionen
einzubauen, durch das ganze Information Hiding und überladen kann es
geschehen, dass man das was ein Programm tut gar nicht mehr sieht.
IMR gibt es so eine 'helloworld.cpp' Parodie.
Das sieht etwa so aus:1 | main() |
2 | { blub b; }
|
Der Rest wird in der classe blubb und ihren Constructor versteckt die sich natürlich in einer anderen Datei befindet.
1 | class blub |
2 | { public:
|
3 | create_blubb(); |
4 | }; |
5 | |
6 | blub::create_blub() |
7 | {
|
8 | cout << "Hello, World\n"; |
9 | } |
Wenn mann OOProgrammierer darauf aufmerksam macht, dass ihre Programme schlecht lesbar sind, dann kontern sie mit Argumenten dass eine gute IDE ihnen auch ganz tolle Class Browser zur Verfügung stellen und dass man nicht wissen muss was in einer Klasse ist da diese mit der IDE mitgeliefert werden. (einige halten Softwareentwicklung ohne IDE für schlicht unmöglich) --- BTW.: Normale Programmiersprachen verbieten dir nicht, dass du Objekte mit eigenen Konstruktoren und Destruktoren erstellst, sie zwingen dich nur nicht diese zu benutzen bzw. sie stellen keine Mechanismen zur Verfügung damit diese automatisch genutzt werden. Das heist wenn du einen Konstruktor für die Class blub hast, dann sieht man dass er irgendwo aufgerufen wird.
1 | main() |
2 | {
|
3 | b=create_blub(); |
4 | } |
@Gerd Dein Beispiel zeigt einen Seiteneffekt (ausgabe von "Hello, World") der irgendwo in einem Programm an einer Stelle versteckt ist, an der man ihn nicht vermutet. Dies lässt sich mit allen Programmiertechniken bewerkstelligen und zeugt lediglich von schlechtem Programmierstil. Mit OOP an sich hat das wenig zu tun.
Deinem "Konstruktor" create_blub() sieht man schliesslich auch nicht an, das das Ding noch was ausgibt...
eine gute klasse hat methodennamen, die eindeutig angeben, was passiert. ausserdem ists für code-recycling vorteilhaft oop zu benutzen, da eine klasse nunmal eine einheit ist, die auch alleine zu funktionieren hat
Also, ich muss meine Meinung ändern. Mit C fühle ich mich frei wie ein Vogel ( Erinnert mich ein wenig an meine Pascal Zeit ). Ich komme eigentlich aus der Java und C# Ecke. Unter C kann ich meine eigene Struktur die ich im Kopf habe fast 1:1 umsetzten, was bei Java nicht so gut klappt. Habe aber das Problem das ich dazu neige für jeden scheiss eine Funktion zu erstellen. mirki
Hat jemand schon die NanoVM ausprobiert ? Sorry, das ich den alten thread rausgeholt habe mirki
> @ Thomas > ich erlaube mir einen Punkt hinzu zu fügen : > d) bei Java hat Smalltalk alles versaut. Naja, die Dinge die ich an Java weniger mag, stammen allesamt nicht von Smalltalk.
> Habe aber das Problem das ich dazu neige für jeden scheiss > eine Funktion zu erstellen. Was heutzutage i.d.R. genau das Gegenteil, nämlich ein Vorteil, ist. Lieber viele kleine Funktionen mit einer jeweils genau definierten Aufgabe als eine Monster-Funktion, die zehn Sachen selbst macht. Funktionsaufrufe sind meist sehr billig, da so kleine Funktionen eh häufig wegoptimiert werden, falls man nicht gerade Rekursion einsetzt.
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.