Dinonator

@AuronX ich gebs auf und fang neu an. ;-) Traum für mich wäre: Ein Masterbrick der ein bisschen Speicher für ein Script hat und ein Script ausführen kann. Die Sprache in der ich das Script schreiben muss ist mir egal, da der Masterbrick als Interpreter funktioniert, der eben ausschließlich nur die Funktionen der jeweiligen Bricks und Brickletts unterstützt. So könnte ich dann z.B. eine Lüftersteuerung für ein Server-Rack standalone betreiben. Ohne einen großen Ballast. Denn ich habe gelernt bzw. lernen müssen, je einfacher etwas programmiert ist, desto stabiler läuft es. Die komplette Hardware-Abtraktion würde dann in dem Masterbrick stattfinden. Parameterfehler usw. würden intern abgefangt werden. Eine Simulationsumgebung lässt sich sehr einfach dann als Programm am PC realisieren. Kompilieren muss man da nichts. Die jeweiligen Funktionen des Scripts die der Interpreter dann ausführt, sind am Brick in bereits kompilierter Form (in der Firmware) abgelegt. Ich kann nur durch den Aufruf der Funktionen etwas bewirken. Will an die internen Funktionen gar nicht ran kommen bzw. sie verändern. Für meinen Teil. Einer eigenen Firmware würde aber nichts entgegen stehen, wenn jemand es auf eigene "Gefahr" hin wünscht. Nochmal ein Beispiel für ein Polling: ---------------------------------------------------- POLLRATE = 100 //in ms Mainloop Start If tempbricklet("TMP1").get_temperature() > 35 then dualrelaybricklet("DR1").set_state(True, False) endif Mainloop End ---------------------------------------------------- Schöne Grüße.

@raphael_vogel "Der größe Teil...." :-D :-D Leute, tut bitte das Ganze lesen und nicht nur einen Fetzen rausreissen um zu herumzutrollen. Habe ich von Java geredet? Habe ich die Sprache angekreidet? Es interessiert mich gar nicht über irgend eine Sprache zu diskutieren. Dann pack doch eine Java-Runtime in einen Brick. Entweder selber oder lass es jemanden machen. Viel Glück. Und bleib beim Threadthema. Verliere nicht die Übersicht. Bin gespannt, wann die "Rechtschreiber" auch noch kommen um ihren Senf dazu abzugeben, ohne dass es was mit dem Thema zu tun hat. Grüße PS: Der Flash hat permanent Lücken und nicht nur erst vor 1-2 Jahren, da scheinst du nicht uptodate zu sein. Ebenso wie die Java-Runtime.

@AuronX Der ganze Thread steckt voll mit Ideen, C, Python oder Java auf dem OnDevice ausführen zu wollen bzw. in diesen Sprachen den OnDevice Brick zu programmieren, weil die eben Leute diese Sprachen können/beherrschen. Genauso war auch die Rede von Py-On-chip usw.. @AuronX + @Equinox Dinonator: "Meine Meinung ist, jede Art von Laufzeit- oder Entwicklungsumgebung in ein Standalone oder "On Device" Gerät zu integrieren ist völliger Humbug." @AuronX Ich will beileibe eben !keine! IDE auf das OnDevice packen. @Equinox Ich habe !nicht! geschrieben, dass ein OnDevice Humbug ist! Equinox: "Warum? Java läuft auf Millionen von Geräten und ist dort keineswegs eine Lachnummer." Schau dir die Größe einer Java und/oder Python Laufzeitumgebung an. viel Spass sowas auf einen OnDevice Brick zu packen. Kuck dir die Nachrichten über Sicherheitlöcher von Java an, permanent Updates, die die Leute dann sowieso wieder nicht einspielen. Die Suchmaschinen sind voll damit. --- Irgend ein Programm muss auf dem OnDevice-Brick bzw. Standalone Brick ausgeführt werden müssen, wenn er Standalone sein soll. Python und Java laufen in einer Laufzeitumgebung. Python sogar interpretiert. Wie soll da eine Stabilität auf dem OnDevice herrschen? Update Orgien auf einem Teil dass 1 Jahr unabhängig laufen soll? usw.... Nicht zu vergessen was den Threadstarter bewegte: Denkt euch ein Script, dass man auf dem Rechner daheim schreibt, testet und dann auf den OnDevice-Brick lädt. Dieses wird dann im OnDevice-Brick (oder eher Standalone-Master-Brick) ausgeführt und übernimmt z.B. mit DualRelay+Temperatur-Bricklet eine Lüftersteurerung. Grüße PS: Sollte ich komplett im falschen Thread sein, sorry. Waren halt nur Gedanken ;-)

Freebasic

Meine Meinung ist, jede Art von Laufzeit- oder Entwicklungsumgebung in ein Standalone oder "On Device" Gerät zu integrieren ist völliger Humbug. Wird zur Bloatware und von den Sicherheitslücken, Updates, Patches usw. möchte ich gar nicht anfangen zu reden. Die Idee mit Java ist die Lachnummer Nr.1. Am Ende bestimmt der Brick oder die Bricklets was "es kann". Wie wäre es mit einer eigenen Script-Sprache, die fest verankerte Funktionen der Teile nutzt? In was für einer Sprache die Funktionen dann am Ende als Maschinecode auf den "Standalone" Brick kommen ist dann leider das Problem bzw. die Aufgabe der Entwickler. Jedoch sind die ganzen Funktionen, die man von C oder Python aus benutzt, schon geschrieben. In diesen Brick könnte man dann eine Main-Loop laufen lassen. Die Scriptsprache trennt bzw. ist die Schnittstelle von Hardware und Software und die Hardware-Abstraktion würde erhalten bleiben. In etwa so: ---------------------------------------------------- POLLRATE = 100 //in ms Mainloop Start: If tempbricklet.get_temperature() > 35 then dualrelaybricklet.set_state(True, False) endif Mainloop End ---------------------------------------------------- Code wird von einem Parser am "großen" Rechner auf Syntax usw. geprüft, bevor das Script auf den Brick kommt. Eine Simulationumgebung wäre auch sehr einfach zu schreiben. Speicherplatz am Brick könnte sehr klein gehalten werden. Man müsste nur die "ID's" der Befehle speichern. Ich denke so eine Variante könnte schon die Anforderungen von 99% der Leute erfüllen. Ist mir schon klar, dass ich hier von einem eigenständigem Rechner mit einem kleinem OS rede. Aber es kommt so oder so drauf hinaus, wenn es Standalone sein soll. Und einen 100er würde ich ohne nachzudenken dafür ausgeben. Nur eine Idee....