On Device Programming: C vs Python

[cfranz]

Hehe, RPython ist spezifisch dafür gedacht Interpreter/VMs zu implementieren. Ein compiliertes RPython "Hello World" Programm ist vermutlich weit größer als die 100Kb die wir zur Verfügung haben. Das wird also nichts

 

OK, da sieht man mal wieder, wie wenig ich von hardware verstehe. Ich bin davon ausgegangen, dass es sich bei dem brick nicht um einen 'refurbished master' handelt, sondern einen eigenen Prozessor mit entsprechendem Speicher in der Grössenordnung 8 MB (für programm und variables) oder mehr hat, der nach dem bootvorgang sein programm z.b. von einer SD-Karte zieht. Wie gesagt, ich verstehe davon nix, aber ein 64mbit chip kostet ca 3.00 EUR in kleinen mengen, weshalb ich davon ausging, dass das preislich kein problem darstellt.

 

100 KB ist weniger als der literal table einer 'hello world' app bei vielen interpretierten sprachen. Autsch. OK, in solchen grössenordnungen hat nur C oder assembler eine chance.

[FabianB]

Ein extra Flash-Speicher-Brick ist nicht vorgesehen und wird es auch definitiv nicht geben (alleine aus technischen Gründen). Was wir mit hoher Wahrscheinlichkeit machen werden ist eine "SD Card Extension", mit der man auf SD Karten loggen kann. Das ist sobald wir ein On Device Programming Interface haben offensichtlich sinnvoll.

Sehr sinnvoll

 

Morgens C, mittags Python und abends TinkerBASIC

 

Klingt zielstrebig 

 

 

Habt ihr denn noch Argumente/Überlegungen, die wir hier noch nicht kennen? Ich habe so langsam das Gefühl, dass alle Argumente auf dem Tisch liegen. Ist es nicht letztlich nur noch eine Entscheidung, wie viel Aufwand ihr dafür betreiben wollt?

TinkerBasic ist doch mehr oder weniger raus. C ist weniger Aufwand, Python mehr, wegen Py-on-Chip-Fork usw. Technische Unterschiede in der Qualität der Ergebnisse gibt es nur wenige, falls ich das richtig verstanden habe. Jeweils 1000N/s, nur wird bei Python nicht der gesamte Befehlssatz unterstützt.Höchstens das Speicherplatzproblem würde noch für C sprechen, oder? Angenommen, dass das keinen relevanten Unterschied macht, bleibt also abzuwägen, wie viel Aufwand eine Benutzerfreundliche Lösung wert ist. Und da Tinkerforges Hauptaugenmerk auf der Einfachheit liegt, spricht das eher für Python...

[borg]

OK, da sieht man mal wieder, wie wenig ich von hardware verstehe. Ich bin davon ausgegangen, dass es sich bei dem brick nicht um einen 'refurbished master' handelt, sondern einen eigenen Prozessor mit entsprechendem Speicher in der Grössenordnung 8 MB (für programm und variables) oder mehr hat, der nach dem bootvorgang sein programm z.b. von einer SD-Karte zieht. Wie gesagt, ich verstehe davon nix, aber ein 64mbit chip kostet ca 3.00 EUR in kleinen mengen, weshalb ich davon ausging, dass das preislich kein problem darstellt.

Es geht hier darum, die existierenden Bricks "On Device" programmieren zu können.

 

Ein "Raspberry PI in Brick-Form" wäre prinzipiell technisch möglich und sehr cool, macht allerdings einfach absolut keinen Sinn. Ein Raspberry PI würde uns bei den 1000er Stückzahlen die wir auflegen sowas wie ~80€ im Einkauf kosten. Zusätzlich hätte unser "Mini Raspberry PI" eine viel kleinere Community und dadurch weniger Support usw. Wir würden davon sicher den ein oder anderen verkaufen, an Leute denen der 4x4cm Formfaktor wichtig ist. Allerdings ist das den Aufwand den uns so ein Brick kosten würde einfach nicht Wert .

 

Als wir gestartet sind war so ein Linux Brick fest geplant, aber da gab es auch noch keine 30€ Linux Boards überall zu kaufen .

 

Mehr Sinn würde es vermutlich machen ein Gehäuse anzubieten in dem man ein Raspberry PI und Bricks befestigen kann. Dazu dann vielleicht noch Kabel um das Raspberry PI über die Step-Down Power Supply zu versorgen und mit einem Brick-Stapel zu verbinden. Könnte dann eins von den neuen Kits sein die wir planen: "Starter Kit: Raspberry PI" .

[borg]

Ich hab den Thread mal getrennt, die Diskussion über den "Super-Master Brick" gibts hier: http://www.tinkerunity.org/forum/index.php/topic,1479.0.html

 

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.

 

Wie ein Linux Brick oder Super-Master Brick aussehen könnte und ob es sinnvoll ist, ist natürlich auch eine interessante Diskussion, die hab ich jetzt mal ausgelagert.

[FabianB]

Danke für die Thread-Trennung!!

Meine Reihenfolge wäre wie gesagt:

1. Python (Wenn es im Vergleich zu der C-Variante die Funktionalität nicht zu extrem einschränkt)

2. C

3. TinkerBasic

 

 

Wie realistisch schätzt ihr (TF) denn die Stemmbarkeit des Aufwands für den Fork von Py-on-a-Chip ein? Welche Prioritäten sind für euch noch wichtig? Nach dem, was wir so wissen, sind vermutlich hierzu die meisten Argumente für C/Python abgewägt worden.

[benatweb]

Ihr könntet doch mal die Autoren von Python-on-a-chip anschreiben. Vielleicht kann man auf dem Weg ja mehr erfahren, warum das Projekt aufgegeben wurde, obs an technischen Problemen oder zu wenig Personal/Interesse lag, und wie die die Sache einschätzen würden. Vielleicht findet sich so ja auch ein Mitstreiter, wenn ihr das weiterführen wollt.

Ist natürlich unklar, ob sich nach so langer Zeit noch jemand meldet, aber schaden kanns ja nicht.

 

Edit: Also zumindest die Google Group hat doch recht akutelle Einträge. Aber keine über weitere Entwicklung...

[Loetkolben]

 

Vielleicht hilft diese Ueberlegung weiter: Was koennte man praktisch auf dem Brick mit C realisieren, was man mit Python nicht koennte, bzw. umgekehrt?

 

Vielleicht kann hier das Tinkerforgeteam etwas zu sagen. Die theoretischen Vor-/Nacteile und Moeglichkeiten der Sprachen sind dem einen oder anderen bekannt, aber was kann davon auf dem Brick wirklich realisiert was die andere Sprache nicht kann?

 

Vielleicht kann das jemand in einer Tabelle zusammenfassen und einen Ueberblick zu bekommen?

 

Der Loetlkolben

[Equinox]

Die Idee/Anfrage von Loetkolben finde gut. Speziell würde mich auch interessieren, was denn bei Python die Einschränkungen sind (bisher habe ich nur gelesen, dass es welche gibt, aber nicht welche).

Ist es z.B. möglich, mit anderen "Clients" zu kommunizieren (gibt es z.B. Sockets, RPC, RMI, oder Ähnliches)? Oder kann man dann "nur" mit den angeschlossenen Bricks und Bricklets kommunizieren?

[Loetkolben]

 

Mir faellt gerade eine Zusatzfrage ein, weil in einem anderen Thread immer nach SD Card zur Datenablage gerufen wird: Wenn schon autonom, dann sollte der Stack auch selbsttaetig Daten senden koennen, bzw. ablegen koennen.

 

Ist ein ftp oder OpenVPN Client ein Ausschlusskriterium fuer eine der beiden Varianten?

 

Im Gegensatz zur Datenabfrage muesste hier bei entfernten Systemen kein Port im Router geoeffnet werden und man kaeme trotzdem an die Daten.

 

Der Loetkolben

[borg]

Sockets/rpc/ftp/openvpn über USB? Oder wie stellt ihr euch das vor?

 

Wir werden sicherlich eine Möglichkeit schaffen um Daten zwischen PC und On Device Programm auszutauschen, das ist z.B. für eine CNC Fräse notwendig (was ja durchaus oft angesprochen wird hier im Forum).

[FabianB]

Vielleicht wäre es möglich, das sowohl über USB als auch optional über die Wifi/Ethernet-Extension zu machen? Das würde Loetkolbens Wunsch vermutlich mehr entgegenkommen.

[Equinox]

Sockets/rpc/ftp/openvpn über USB?

 

Nicht über USB, sondern über WLAN. Vergessen habe ich noch das Anbieten von Web-Services.

[borg]

Vielleicht wäre es möglich, das sowohl über USB als auch optional über die Wifi/Ethernet-Extension zu machen? Das würde Loetkolbens Wunsch vermutlich mehr entgegenkommen.

Das wird ja über unser normales Nachrichtensystem gehen, also auch über WLAN/Ethernet.

 

Sockets/rpc/ftp/openvpn über USB?

 

Nicht über USB, sondern über WLAN. Vergessen habe ich noch das Anbieten von Web-Services.

 

In Theorie kann man sich mit der WIFI Extension auf einen ftp Server verbinden oder einen Webservice anbieten. Das wäre aber etwas was es in erster Instanz von uns direkt als API nicht geben wird.

 

Wer sich damit beschäftigen möchte kann das aber natürlich, ist ja alles Open Source und die Datenblätter liegen mit im git: https://github.com/Tinkerforge/wifi-extension/raw/master/datasheets/GS1011M_Adapter_Guide.pdf

 

 

Also in erster Instanz (unabhängig von der Sprache) wird man per On Device die API haben die man extern auch hat und eine Möglichkeit Daten mit dem PC auszutauschen. Wenn es da die ersten Projekte gibt kann man anfangen zu gucken inwiefern es Sinn macht die API um On-Device-spezifische Funktionen zu erweitern. Eine einfache Möglichkeit einen kleinen Webservice anzubieten wäre da durchaus im Rahmen des möglichen.

[Equinox]

Hmmm, ich glaube wir reden aneinander vorbei. Die Frage war, ob die (vorgesehene) abgespeckte Version von Python/C dies unterstützt. Ich denke nicht, dass das Dinge sind, die in die TF-API sollten, wenn es schon "native" möglich ist.

Sprich: Können die erwähnten Dinge mit den vorgesehenen (möglichen) Versionen von Python/C/TinkerBasic gemacht werden oder sind diese Möglichkeiten bei den Versionen dem "Abspecken" zum Opfer gefallen? Was sind genau die Dinge, die dem "Abspecken" zum Opfer gefallen sind?

[Nic]

Hmmh, im ersten Moment war ich geneigt mich für Phyton auszusprechen, aber wenn hierzu ein totes OpenSource-Projekt reaktiviert werden muss, frage ich mich ob es nicht sinnvoller ist, die Zeit und Ressourcen lieber gleich in die Entwicklung einer vernünftigen C-API zu investieren.

 

Als Vorlage die Ardunio-API, aber ev. idiotensicherer -wenn das überhaupt geht- , dass C-Abstinenzler wie z.B. ich, schneller einen Einstieg haben und weniger graue Haaare bekommen. Solche Fallstricke wie Speichermanagement etc. könnte man ev. kapseln und vom Normalo-Programmierer fernhalten ?!

 

Ich verwende TF erstrangig für mobile Anwendungen da ist es mir wichtiger, mich auf eine robuste API zu verlassen als mit einem besch...Betriebssystem oder unausgereiftem, wackeligen OnChip Interpreter in der Pampa zu ärgern. Meinetwegen beiße ich auch dafür in den "sauren" C-Apfel .

[Loetkolben]

Wegen ftp/openvpn

 

Bitte an die Wetterstationsfraktion denken:

Stack wird mit WLAN oder Ethernet vorkonfiguriert verschickt. Wie komme ich an die Daten? Entweder durch Portoeffnung am Router bei Tante Erna oder wenn der Stack selbst die Daten "aussen" ablegt, bzw. verschickt.

 

Der Loetkolben

[rifmetroid]

@TF

 

Wie sieht es denn nun jetzt hier aus? Habt ihr schon eine Entscheidung getroffen ob nun C, Python, oder TinkerBasic?

[Dinonator]

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

[AuronX]

Ich verstehe ungefähr die erste Häfte deines Beitrages nicht. Also ich verstehe nicht was du sagen willst und bin mir nicht sicher ob du verstanden hast was das Ziel ist (Ziel ist es nicht eine IDE aufs Brick zu bringen).

[Equinox]

Meine Meinung ist, jede Art von Laufzeit- oder Entwicklungsumgebung in ein Standalone oder "On Device" Gerät zu integrieren ist völliger Humbug.

Von einer Entwicklungsumgebung war ja auch nie die Rede (wobei ich das gar nicht so schlecht finden würde). Aber warum sollte OnDevice Humbug sein? Und warum sagst du, dass es Humbug sei und schlägst dann ein kleines, eigenes OS vor?

Die Idee mit Java ist die Lachnummer Nr.1.

Warum? Java läuft auf Millionen von Geräten und ist dort keineswegs eine Lachnummer.

[Dinonator]

@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 ;-)

[raphael_vogel]

Das Argument mit den vielen Sicherheitslücken von Java ist hier fehl am Platz. Der große Teil der Lücken bezieht sich doch auf die Browser Plug-Ins (Applet/ActiveX) und hat mit der Sprache an sich nichts zu tun. Es ist ein Problem einer Technologie nicht einer Programmiersprache.

Vor ca. 1-2 Jahren war es der Flash Player der für Schlagzeilen gesorgt hat. Da hat auch keiner gesagt dass C oder C++ oder ActionScript Scheisse ist.

 

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

Leute, tut bitte das Ganze lesen und nicht nur einen Fetzen rausreissen um zu herumzutrollen.

 

Ganz ruhig, niemand will trollen... aber wenn man nicht zu allen Argumenten gleichzeitig etwas sagen will oder kann, dann sagt man etwas zu denen zu denen man etwas sagen kann. Das tue ich jetzt auch:

 

Ich will beileibe eben !keine! IDE auf das OnDevice packen.

 

Da du das gesagt hast, ohne dass es zuvor im Thread als Idee aufkam wollte ich sichergehen, ob du alles richtig verstanden hast. Du bist quasi initiativ auf das Thema eingegangen...

 

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.

 

Tatsächlich sind die Sicherheitslücken in "Java" ziemlich irrelevant:

[*]Sie betreffen nicht das Konzept der Sprache sondern die konkrete Implementierung der JRE

[*]Die JRE wäre für das Brick unabhängig der Software-JRE implementiert, möglicherweise sogar von anderen Herstellern (das heißt nicht, dass es frei von Lücken wäre... es sind nur vollkommen unabhängige Lücken)

[*]Alle Lücken betrafen nur den Browser, da es dort ein erstrebenswertes Ziel ist an höhere Privilegien zu gelangen, diese hat man außerhalb des Browsers oder gar auf einem Brick sowieso

 

Last but not least wurde Java aufgrund anderer Kritieren schon nahezu ausgeschlossen, denke aber Sicherheitsbedenken sollten im vorliegenden Fall am wenigsten ausschlaggebend sein.

 

Python sogar interpretiert.

 

Ist reines Implementierungsdetail. Python könnte auch kompiliert ausgeführt werden (wird es zum Teil auch) und man könnte C auch interpretiert ausführen. Zu ersterem siehe auch den Teil den ich schon zum Thema geschrieben habe.

 

Wenn ich deine Idee richtig verstanden habe würdest du gerne eine neue Sprache haben, um in dieser einige wenige Grundfunktionen umsetzen zu können. Den Code würdest du normal auf dem PC kompilieren (lies als: "Brickfertig machen").

 

Da frage ich: Warum kann für diesen Zweck nicht eine Untermenge einer bereits existierenden Sprache herhalten?

[raphael_vogel]

@Dinonator

Ja genau, beim Threadthema bleiben. Daher hab ich mich auch gefragt was Sicherheitslöcher von Java in der Presse mit der On-Device Thematik zu tun haben.