Dinonator
-
Gesamte Inhalte
5 -
Benutzer seit
-
Letzter Besuch
Posts erstellt von Dinonator
-
-
@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
Hey Franz, ja das hast du ziemlich richtig mitbekommen. Es soll aber eigentlich direkt auf der existierenden Hardware laufen (möglicherweise mit einem anderen Firmware-Image).
Ob es nur ein Problem der Toolchain ist, ist noch die große Frage.
C auf dem Brick auszuführen geht erstmal recht simpel, wenn du Python ausführen willst gibt es verschiedene Optionen:
1. Es geht gar nicht (zumindest nciht für TF bezahlbar)
2. Es geht, Python-Skripte werden nativ auf dem Brick ausgeführt (dann geht villt keine C-API mehr weil zu wenig Speicher auf dem brick vorhanden ist für alles gleichzeitig)
3. Es geht, Python-Skripte können mit passenden Tools kompiliert und aufs Brick geladen werden (C läuft nativ); hier wäre es nur eine Frage der Tools
Wir werden ein On Device Programming Interface für die existierenden Bricks anbieten. Da brauchen wir nicht drüber diskutieren. Hier geht es jetzt darum wie so ein Interface aussehen könnte.
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:
Moin,
danke für euer Feedback! Hilft uns dabei wiedermal den Blick zu schärfen.
Was haltet ihr denn für interessanter?
Eine On Device API für C, mit der ihr eigene Firmwares schreiben könnt und die ähnlich wie bei Arduino zugriff auf den ADC ermöglicht etc.
Oder eine Implementierung der Python Bindings auf den Bricks?
D.h. man könnte ein Programm in Python schreiben, dies auf dem Rechner testen und dann das Programm auf die Bricks übertragen. Danach würd das ganze Stand-alone ausgeführt. Wobei kein "vollständiges" Python von uns unterstützt werden könnte. Es würden alle grundlegenden Spracheigenschaften unterstützt aber z.B. nicht externe Bibliotheken.
Beide Möglichkeiten sind sehr viel Aufwand und ermöglichen es nur "eine Sprache" zu nutzen. Java wäre z.B. nicht nutzbar.
Habt ihr eine Meinung dazu?
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 ;-)
-
-
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....
On Device Programming: C vs Python
in Allgemeine Diskussionen
Geschrieben
@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.