Vielleicht bin ich ja verrückt !?

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

Warum dann nicht einen ARM?

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

vielleicht fuer denkanstoesse
google: tinyvm

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

Ich weiss nicht, 128 kb halte ich für zu wenig für die VM.

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

Hallo

das ist das Projekt welches ich beobachte:==>https://jdos.dev.java.net

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.