Hallo mlade,

zu 1)
a) Die ASURO Methoden Sleep() und Msleep() - so wie sie in HaikuVM implementiert sind - funktionieren nur mit einem Atmega8.
b) Ich hatte die Hoffnung, dass der "nibobee-programmer" eine EXE Datei ist die auch Commandline Optionen versteht. Dann nämlich kann ich ihn in der nächsten Version als
Code:
nibobee.Upload = nibobee-programmer.exe option1 option2 ... $(HAIKU_OUTPUT)
in 'HaikuVM.properties' einbauen.

zu 3) Leider ist dein Code unleserlich. Editier doch bitte deine Post noch einmal und schließ ihn in einen CODE-Block ein. Würde mich freuen.

7) "nächste Frage" pushTop(): Zunächst einmal sollte an diesen automatisch generierten Funktionen 'native_*' wirklich nichts verändert werden, sonst kommt die HaikuVM durcheinander.
Die JAVA VM ist im Wesentlichen eine Stackmaschine (also auch HaikuVM). Alle Operationen geschehen auf dem Stack. Das ist ein ewiges auf und ab (push und pop). Beispiel 3 + 4:
Code:
push(3);
push(4);
push(pop() + pop());
Jetzt steht das Resultat 7 auf dem Stacktop und man hat dazu 5 push&pop gebraucht.

Besonders heiß geht es am Stacktop zu. Wenn man das weiß kann man push&pop sparen indem man den Stacktop gerade nicht auf dem Stack hält, sondern in einer Variablen (hier top):
Code:
push(top); top=3;
push(top); top=4;
top=(top + pop());
Jetzt steht das Resultat 7 in top und man hat nur 3 push&pop gebraucht. (Da ich push(top) oft brauche gibt es die Abkürzung pushTop().)
Jetzt zu deiner Frage:
Irgendwas ist immer in top. Da aber getTimer2() keinen Parameter braucht kann der Inhalt von top nicht für getTimer2() bestimmt sein. Deshalb muß ich top sichern ( und zwar auf den Stack mittels pushTop() ) bevor top von 'Java_avr_tutorial_Interrupt1_getTimer2(env, obj)' überschrieben wird.

8 ) Und ... ich muß dir widersprechen: HaikuVM ist unbedingt auch für die direkte Kommunikation mit der Hardware gedacht. Das was man in C sonst in Interrupt Routinen macht sollte man in HaikuVM mit parallelen Threads lösen. (Ähnlich wie die Propellerchips sehr gut ohne Interrupts aus kommen.)