On Device Programming: C vs Python

[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.

[rifmetroid]

Moin,

gibt es hierzu schon eine Entscheidung von TF?

In der Timeline konnte ich dazu nichts finden, wäre aber sehr an dem Thema interessiert.

 

Gruß

rif

[pluto]

Wie war es noch gleich: Was ist besser: Ein Apfel oder eine Birne? Ich bin für Orangen *G*

Daher: Warum nicht gleich Pascal nehmen? 

 

Oder es noch "besser" machen, Der MasterBrick bzw. ein extra Brick könnte es dafür geben, führt einen eigenen Binären Code aus.

 

Binären code kann man in jeder Sprache erzeugen(denke ich mal). Übersehe ich was?

Das würde sogar zur euren Jetzigen Konzept passen... Ich weiß nicht in wie weit die Code Generatoren angepasst werden müssen.

 

Was haltet ihr davon? So könnte man die API'S entsprechend einfach erweitert um die Möglichkeit den Code direkt auf die Hardware zu bringen.

 

Ich denke aber auch, die Art und weise wie die Programmierung aussieht ist Wichtiger Punkt.

Wurde darüber schon gesprochen?

(Ein einfaches Ja/Nein genügt mir)

Ich habe den Thread nicht von Anfang an Verfolgt(leider).

 

z.b. was genau kann man Programmieren bzw. was soll man Programmieren können z.. stelle ich mir am IO16 Brick ein Schalter vor, der eine LED an und ausmacht. Oder ich könnte mir ein LCD Vorstellen, wo direkt Sensor Werte angezeigt werden.

Natürlich wird schnell die Frage aufkommen: Wie könnten die Sensor Werte abgespeichert werden? Am besten auf eine SD Karte *G*. Da könnte es ein extra Brick für geben, was meint ihr?

 

Ach ja, wenn wir schon mal dabei sind: Ein Takt Geber wäre eine Einfache Sache, um zum Beispiel zu sagen: Speichere jetzt alle 10 Minuten die Temperatur oder schalte die LED alle 2 Sekunden aus oder so oder auch für das Auswerten von Fernbedinungs Signalen. Wäre ein Takt Geber sehr Praktisch.

 

Vielleicht könnte man das in ein extra Zweig auslagern.

 

[raphael_vogel]

JavaScript ist ja zur Zeit sehr angesagt. Nicht nur auf dem Client sondern auch auf dem Server (node.js).

 

Wäre das nicht auch eine schlanke Alternative für On Device?

Die Sprache ist mittlerweile sehr weit verbreitet und es gibt anscheinend auch Microcontroler die JS interpretieren können: http://tessel.io/

 

Damit könnte man mit EINER Sprache alles abdecken (vom GUI über den Server bis zur Hardware), wenn TF dann noch Bindings für JS rausbringt