On Device Programming: C vs Python

[Equinox]

Wie schon einige vor mir, bin ich auch der Meinung, dass der Fokus nicht auf der Geschwindigkeit liegen sollte, sondern auf der Anwendbarkeit bzw. Nutzbarkeit (zumal noch nicht wirklich viele Beispiele für 1000N/s gekommen sind). Ich denke, dass es zunächst einfach mal wichtig ist, ohne Rechner TF nutzen zu können, und das möglichst einfach, was für mich ganz klar für eine Hochsprache (höher als C) spricht. Aus meiner Sicht reichen die 200 N/s mit einer JVM locker aus und würde On Device Programming für sehr viele interessant machen.

[ArcaneDraconum]

Ich würde auch sagen, die "Bauklötzchenfraktion" kommt mit einer "geringeren" Leistung ganz gut zurecht, benötigt aber einen einfachen Zugang zur Materie. Ich hänge da nach wie vor an Python. Andernfalls muss ich eben ein bischen was dazu lernen - wenn die Doku gut ist kein Problem, ansonsten hat man ja noch das fabelhafte Forum hier.

[FabianB]

Aus meiner Sicht reichen die 200 N/s mit einer JVM locker aus und würde On Device Programming für sehr viele interessant machen.

 

Das sehe ich anders. 1000 N/s ok, das reicht wirklich für die allermeisten, auch komplexeren Sachen. Aber 200 hat man schon deutlich schnller voll. Ein paar Listener mit hoher Abfragefrequenz (die du bei "live"-Funktionalitäten hast) machen dir das schon voll.

Nicht über 1000 zu gehen ist absolut ok, weil die Menge der machbaren Projekte damit nur minimal eingeschränkt wird. Bei 200 finde ich die Einschränkung zu groß, das sehe ich sogar schon in dem Bereich, der einige Kunden abhalten könnte.

Mag sein, dass ich das übertrieben sehe, aber ich schätze das im Moment so ein.

 

Für Java wäre ich deswegen absolut nicht (obwohl ich selbst am meisten in Java programmiere).

 

Ehrlich gesagt verstehe ich die Argumente für Python nicht so genau (außer, dass man sagt, Python kann ich schon, ich müsste nichts lernen). Für alle, die Python nicht können, ist es egal, ob sie Python oder oberflächlich C lernen müssen.

C bietet dabei aber einige Vorteile: Typisch für diese Art der Anwendung, flexibler, weniger Einschränkung als mit Python, C-API ist von TF schneller zu machen...

 

@Python-Vertreter: Bitte klärt mich auf :-) Was spricht sonst noch für Python, außer, dass ihr das könnt?

 

(Bitte meinen Post nicht böse auffassen. Falls er so klingt: Ist nicht so gemeint. Ich will niemandem blöd kommen.)

[batti]

Diese 200N/sek bezogen sich auf Java. Weil die Implementierung davon halt recht komplex ist. Eine deutlich einfacher gestricke Sprache, die vll. auf nem Basic basiert sollte auch die besagten 1000N/s erreichen.

 

Eine Idee wäre es sich eine wirklich minimale Sprache zu Suchen und diese dann ggf. um eigene Keywords zu erweitern. Z.B. sowas wie registerCallback o.ä. Am Ende hätte man dann eine "eigene" Sprache, z.B. sowas wie TinkerBasic 

[FabianB]

Eine Idee wäre es sich eine wirklich minimale Sprache zu Suchen und diese dann ggf. um eigene Keywords zu erweitern. Z.B. sowas wie registerCallback o.ä. Am Ende hätte man dann eine "eigene" Sprache, z.B. sowas wie TinkerBasic 

 

Eine schöne Idee, aber dann ist das mit deutlich mehr Aufwand in der Herstellung verbunden. Außerdem wäre "TinkerBasic" nicht kompatibel zu anderen Projekten/Erfahrungen etc.

Und warum das Rad neu erfinden? Abgesehen von den Namen der Schlüsselbegriffe wäre TinkerBasic doch auch nicht anders als ein "oberflächliches" C.

 

 

Ich muss nochmal penetrant sein  :

 

Kern meiner Thesen ist, dass ich davon überzeugt bin, dass man der Variante mit C die Anwendungsschwierigkeit nimmt, indem man eine gute API bereitstellt, sodass nur noch ein ganz einfaches C verwendet werden muss.

Dieses würde sich dann kaum von anderen Sprachen (Java, Python, TinkerBasic) unterscheiden, aber halt einige bereits genannte Vorteile mehr mitbringen.

[AuronX]

Also:

Python ist eine moderne objekt-orientierte Sprache.

C ist alt, erfordert viel unnützes Detail-wissen und ist Fehleranfällig (manuelle Speicherverwaltung!!!!)

 

So, das war jetzt ein wenig polemisch aber im Wesentlichen spiegelt es meine Sicht der Programmierwelt wider. Oft wird bei C ein Performance-Argument gebracht, ohne dass jemand Zahlen dazu hat.

Sprachen sind von Hause aus eh nicht schnell oder langsam, deren Ausführung in der Praxis vielleicht.

 

Also Pro-Python:

• leichter erlernbar (wenn man vorher nichts kennt)
  
• weniger Fehleranfällig
  
• objekt-orientiert
  

 

Und jetzt nochmal ein großes ABER:

 

TinkerBASIC?? Da bin ich tatsächlich auch nicht so sehr von überzeugt. Ich würde definitiv dafür plädieren etwas existierendes, mit bestehender Community zu verwenden. Wenn ihr jetzt eine eigene Sprache nehmt, dann kann man gar keine existierende Software portieren und niemand hat Vorwissen.

 

Also meine persönliche Reihenfolge:

[*]Python

[*]C

[*]Tinker

[Equinox]

Um es gleich voraus zu schicken: Ich kann weder Python noch (richtig) C (deshalb bin ich ja auch für Java). Für Python spricht die leichtere Erlernbarkeit und der unkompliziertere Umgang, da es eben nicht compiliert werden muss. Klar, dadurch ist es langsamer, aber wenn ich daran denke, dass ich ein C-Programm compilieren und dann evtl. noch irgendwie mit zusammen mit dem Firmware-Code flashen muss, dann stellen sich mir alle Haare zu Berge.

Ein "oberflächliches" C wäre meiner Meinung nach auch zu proprietär. D.h., wenn ich schon eine neue Programmiersprache lernen muss, dann sollte sie auch anderweitig einsetzbar sein.

Ich denke auch, dass die allgemein die Hemmschwelle bei Python geringer ist. Und es sollen ja möglichst viele in den Genuss kommen, ohne Rechner die TF-Teile nutzen zu können.

[AuronX]

Für Performance-Fanatiker: Sprachen sind nicht per se langsam, sie werden potenziell langsam ausgeführt.

 

Es ist möglich Python (genauer ein Subset von Python) zu C-Code oder Maschinen-Code zu kompilieren.

 

Aber das sind alles Technologiefragen. Das heißt man könnte einen Chip nehmen (wie die Java-Geschichte), man könnte auf dem aktuellen ARM einen Python-Interpreter implementieren oder man könnte es unterstützen den Python-Code zu kompilieren und das auszuführen.

 

Mehr Detail: PyPy

[FabianB]

Ok, drei gute Argumente. Ich habe gerade mal funktionsidentischen Code von C und Python nebeneinandergehalten. Ich bleibe zwar dabei, dass ein einfaches C zumutbar wäre, aber ich sehe ein, dass Python schon anwenderfreundlicher wäre. Du könntest mich überzeugt haben... 

Was mich noch von einer Zustimmung abhält, ist das Folgende:

 

@TF: Was waren nochmal die Einschränkungen die eine Umsetzung mit Python mit sich bringen würde? Ihr hattet da mal was erwähnt. Eingeschränkter Funktionsumfang oder so.

Könntet ihr das nochmal präzisieren? Damit man besser abschätzen kann, wie schwer das in der realen Anwendung wirklich wiegen würde. Welche konkrete Funktionalität ließe sich mit der Python-Variante nicht realisieren. Welche technischen Einschränkungen/Nachteile hätte das?

[ArcaneDraconum]

@Fabian: Genau Du hast es richtig vermutet, ich ziehe Python vor, weil ich es kann. Ich habe alle Projekte bisher in Python realisiert und somit ist es für mich etwas einfacher - denn neben der Sprache kommen ja noch die Hardwarespezifischen Aspekte dazu.

Python ist quasi von einem Anbieter für alle Platformen zu bekommen. Bei C ist es ja ein wenig anders - meine ich.

Gut Java ist natürlich wieder plattformunabhängig. Ein Plus dafür. Ich sitze halt mal an einem MacBook und mal an einer Windowsmaschine.

[FabianB]

Also für mich ist Java völlig außen vor. Hat für mich keine Vorteile, nur ein paar Nachteile. Ich sehe keinen Vorteil von Java gegenüber Python.

 

 

Was mich zu dem Schwenk von C zu Python bewegen könnte, wäre, dass es halt noch einfacher wäre als ein rudimentäres C. Dass ich identischen Code gegeneinandergehalten habe, hat mich von meiner verfestigten C-Position gelöst :-D

Allerdings nur dann, wenn Python keine nennenswerten technischen Nachteile mit sich bringt. Ich finde es wichtig, dass die mäßig komplexeren und anspruchsvolleren Projekte mit der OnDevice API realisierbar sind. Vor allem mobile Dinge wie Roboter oder Quadrocopter sollten problemlos machbar sein.

Extremere Ansprüche wie sie in der Industrie eventuell gebraucht werden, sollten dahingegen erstmal vernachlässigt werden.

 

 

Was du zur Plattformabhängigkeit sagst, ist lösbar. Egal welche Sprache, TF könnte in der Doku die jeweils funktionierenden Compilerversionen etc. für alle Plattformen verlinken. Das wäre zwar nicht schön, stellt aber in meinen Augen keinen schwerwiegenden Nachteil dar.

[AuronX]

Ich frage mich nach meiner 20-Minütigen Recherche inzwischen, ob nicht C und Python möglich sind.

 

Habe ja vorhin die RPython-Toolchain von PyPy hier im Thread verlinkt. Dabei handelt es sich um Tools die aus Python-Code C-Code machen und kompilieren.

 

Ich habe das noch nicht selbst genutzt, es wäre also weitere Forschung nötig, aber grundsätzlich könnte es möglich sein, dass auf diese Weise sowohl C (nativ) als auch Python (durch die RPython-Toolchain) supported werden könnte.

 

Ein großes Fragezeichen, aufgrund der aktuellen Diskussion aber möglicherweise die Forschung wert.

[FabianB]

Irgendwie möglich kann ich mir gut vorstellen. Aber ich stelle mir das auch zu aufwendig für die Umsetzung vor.Wenn das gut umsetzbar wäre, hättest du natürlich die Mutter aller Kompromisse gefunden :-D Da lohnt sich wirklich ein genauerer Blick.

 

 

@TF: Hattet ihr nicht schon einen anderen Ansatz zu Python als PyPy in der Schublade liegen? Ich meine mich da an einen Post zu erinnern, kann aber sein, dass ich spinne.

[AuronX]

Das war das hier:

http://code.google.com/p/python-on-a-chip/

 

Da kam dann die berechtigte Frage warum die latest News von September 2011 sind. Die Commits sind ähnlich alt, das Projekt sieht also tot aus...

[FabianB]

Danke. Sieht wirklich tot aus. Schade, unabhängig von der Verwendung hier.

Naja, wenn man sich aber nicht die selber die Weiterentwicklung eines solchen Projekts antun will, sollte man sich nicht erst auf ein totes Pferd setzen.

Ok, mal sehen. Bin mal gespannt, was die TFler demnächst so berichten. Vielleicht haben sie sich ja schon entschieden oder bringen noch ein paar Infos oder Vorschläge.

[cfranz]

Ich bin mir nicht sicher, dass ich die diskussion ganz verstehe, aber ich bin eventuell auch zu spät erst dazugestossen.

 

Meine Annahme: Ihr wollt einen TF block herausbringen, der die bricks/bricklets direkt steuert, also quasi die Daemon/PC-kombination ersetzt.

 

Nun scheint die Frage zu sein, ob der brick eher in C oder Python programmiert werden soll.

 

Meine Frage: wieso 'oder'? Soweit ich weiss, ist Py eine interpretierte Sprache, C wird kompiliert (also direkter maschinencode). Aus meiner Sicht (die sehr beschränkten ist, immerhin habe ich das letzte mal vor gut 20 jahren einen compiler geschrieben)  sind im Endeffekt beide das gleiche. Ein interpretiertes Programm wird halt mit dem Interpreter plus Library und dem byte/tokencode auf den brick gebracht. Ein voll compiliertes programm wird direkt aufgespielt. Das ist doch 'bloss' ein Problem deiner Toolchain. Kann euer compiler nicht automatisch den python zwischencode mit einem interpreter verpacken und als maschinencode auf den chip bringen?

 

Alternativ könntet ihr den chip do entweder als Py engine oder 'straight machine' flashen. So können die C heads direkt (schnelle programme), die pythoners den interpretierten code draufknallen. Und die community kann dann noch interpreter für andere dialekte (z.b. das erwähnte TF-Basic) dazu schreiben

 

Was habe ich übersehen?

 

-ch

 

[eine sache die ich nicht geschnallt habe: wieso wird C hier als Guru-Sprache bezeichnet? C++ meinetwegen. Aber oldskool C ist eher ein glorifizierter Macroassemberl. Das ist nur unbequem, nicht schwierig. Py ist hat viel eleganter.]

 

[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

 

Das ist mein aktueller Irrtumsstand, die Frage ist jetzt was braucht man und was kann TF leisten.

[The_Real_Black]

Zu meiner Anwendung: Ich würde einen Brick benötigen, welcher auf definierte Events\Callbacks in den Stack Befehle absetzt, aber ansonsten die normale Kommunikation nicht beeinträchtigt.

Beispiele:

Verbindung WIFI bricht ab -> DC 1 und 2 schalten ab.

IO16 hat auf Pin 1 oder 8 ein Signal -> DC's aus -> warte x ms -> dc zurück.

...

Ansonsten bleibt die Verbindung per USB oder WIFI zum PC erhalten.

Im Grunde würde mir ein "Plugin" in die normale Firmware genügen welche x mal in der Sekunde ausgeführt wird.

 

Die Idee von cfranz, dass man beide Sprachen realisiert wäre auch ein Ansatz und dann müssten hier eine Einschnitte gemacht werden.

[cfranz]

Wenn es simple ist, c (compiliert neheme ich an) auszuführen, dann sollte es auch einfach sein (sofern der speicher gross genug ist) auch beliebige interpretierte sprachen auszuführen. Bspw wird ein Py programm zusammen mit dem interpreter als compiliertes c programm geladen. Der interpreter wird ausgeführt und lässt dann das Py programm laufen. Bereits der alte Apple II funtionierte 1977 mit BASIC so.

Wenn es also einen open source Py interpreter gibt, sollte es nicht allzu schwierig sein, so etwas zusammenzuschustern. Der c brick wird also jedesmal mit einem paket bestehend aus interpreter und Py programm geladen. Oder mit einem basic-interpreter und zugehörigem basic-programm etc.

 

Aber evtl habe ich die ausgangslage nicht voll verstanden. Ich ging davon aus, dass auf dem brick ein prozessor läuft, der einen native maschinencode benötigt. Wenn ich dich richtig verstehe, läuft auf dem brick aber Py native? Hab ich das richtig verstanden?

 

Was sind zur zeit die Parameter, die für so ein programmierbares device gelten? Ich dachte ein prozessor, der mit maschinensprache programmiert wird, ein paar MB RAM und etwas IO.

[Equinox]

Um doch nochmals Java ins Spiel zu bringen: Die Plattformunabhängigkeit ist doch ein geniales Argument dafür. Man könnte seine Programme ausführlich auf einem PC/Mac/Raspi testen und sie dann völlig unverändert auf den TF-Stapel schieben. Ist doch super, oder?

[benatweb]

Aber evtl habe ich die ausgangslage nicht voll verstanden. Ich ging davon aus, dass auf dem brick ein prozessor läuft, der einen native maschinencode benötigt. Wenn ich dich richtig verstehe, läuft auf dem brick aber Py native? Hab ich das richtig verstanden?

Nein, auf den Bricks läuft eine in C geschriebene Firmware. Python ließe sich über einen Interpreter auf dem Brick (oder evtl. einem Python -> C Übersetzer) nutzen.

 

@equinox

Das selbe gilt aber ganz genauso für Python. Und es wurde ja schon gesagt, das Java wenn dann nur langsam auf den Bricks möglich wäre. Ich sehe da keinen guten Grund für. (Außer dass es für einige die vertraute Sprache ist)

[borg]

Ich frage mich nach meiner 20-Minütigen Recherche inzwischen, ob nicht C und Python möglich sind.

 

Habe ja vorhin die RPython-Toolchain von PyPy hier im Thread verlinkt. Dabei handelt es sich um Tools die aus Python-Code C-Code machen und kompilieren.

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 .

 

 

Ich hab mir mal simpleRTJ (java vm) und python-on-a-chip näher angesehen.

 

simpleRTJ:

Das kleinste Board auf dem sie das laufen haben hat 64Kb SRAM. Sie schreiben zusätzlich, das man 32Kb für das ausführen einer Applikation frei haben muss. Das sieht definitiv nicht gut aus. Zusätzlich zur bestehenden Firmware würden wir das glaube ich nicht eingebaut kriegen.

 

python-on-a-chip:

An und für sich sieht das gut aus. Der Source Code ist übersichtlich und verständlich. Allerdings, wie AuronX auch schon gesagt hat, ist das Projekt leider tot. Wir müssten es also definitiv forken und selbst weiter führen. Es gibt auch reichlich bekannte Bugs: http://code.google.com/p/python-on-a-chip/issues/list

z.B. stürzt noch in der aktuellsten Version der Interpreter sobald eine Exception auftritt. Das ist schon hart .

[FabianB]

Es hat schon so seine Gründe, dass C für derartige Dinge immer noch so weit verbreitet ist. Die Alternativen sind alle nicht gerade rosig.

Mit einem Fork von python-on-a-chip täte man zwar vielleicht noch anderen Projekten einen Gefallen, aber ich bin da immer noch skeptisch, ob man sich den Aufwand antun sollte.

 

 

@borg: Wozu tendiert ihr denn? Weiterhin zu C?

 

 

 

 

[Equinox]

Das selbe gilt aber ganz genauso für Python. Und es wurde ja schon gesagt, das Java wenn dann nur langsam auf den Bricks möglich wäre. Ich sehe da keinen guten Grund für. (Außer dass es für einige die vertraute Sprache ist)

 

Die Plattformunabhängigkeit gilt für Python nur eingeschränkt. Vtml. würde ein Programm, das auf dem PC entwickelt wird und man ein paar Dinge beachtet auch auf den TF-Bricks laufen. Aber Java ist sehr weit verbreitet (nicht nur bei "einigen") und läuft auf Millionen von Endgeräten. Es wäre doch z.B. super, wenn das Programm unverändert auch auf deinem Android-Handy laufen würde, oder? Mit Python geht das sicher nicht.

Abgesehen davon, glaube ich, dass die 200N/s bei Java für 99,5% der Fälle locker ausreicht. Und Python wird als interpretierte Sprache vmtl. auch nicht an die 1000N/s rankommen.

simpleRTJ:

Das kleinste Board auf dem sie das laufen haben hat 64Kb SRAM. Sie schreiben zusätzlich, das man 32Kb für das ausführen einer Applikation frei haben muss. Das sieht definitiv nicht gut aus. Zusätzlich zur bestehenden Firmware würden wir das glaube ich nicht eingebaut kriegen.

Ok, ich wußte nicht, dass ihr nur 100KB zur Verfügung habt. Das wird mit Java wohl wirklich nicht gehen. Allerdings bin ich auch davon ausgegangen, dass die Programme auf einem extra Speicher-Brick liegen (wie hier vorgeschlagen wurde). Das halte ich in jedem Fall für sinnvoll, egal bei welcher Sprache. Diese Einschränkung (100KB) ist meiner Meinung nach ein größeres Problem als die "nur" 1000N/s.

[borg]

Die Plattformunabhängigkeit gilt für Python nur eingeschränkt. Vtml. würde ein Programm, das auf dem PC entwickelt wird und man ein paar Dinge beachtet auch auf den TF-Bricks laufen. Aber Java ist sehr weit verbreitet (nicht nur bei "einigen") und läuft auf Millionen von Endgeräten. Es wäre doch z.B. super, wenn das Programm unverändert auch auf deinem Android-Handy laufen würde, oder? Mit Python geht das sicher nicht.

Da tut sich nichts zwischen Python und Java. So eine µ-Java-VM unterstützt auch nicht den kompletten Befehlssatz (z.B. werden wir nie double/float unterstützen können).

 

Es gilt sowohl für Java als auch für Python, dass du die komplette Standardbibliothek _nicht_ zur Verfügung hast. Also ein Python/Java Programm was auf dem Brick läuft, läuft auch auf Windows/Mac/Linux/Android. Umgekehrt ist dies mitnichten der Fall.

 

Ok, ich wußte nicht, dass ihr nur 100KB zur Verfügung habt. Das wird mit Java wohl wirklich nicht gehen.

Der Master Brick hat 256KB Flash, davon werden im Moment 120KB von der  Firmware belegt und die letzten 16KB im Flash sind für die Bricklet Plugins reserviert.

 

Allerdings bin ich auch davon ausgegangen, dass die Programme auf einem extra Speicher-Brick liegen (wie hier vorgeschlagen wurde). Das halte ich in jedem Fall für sinnvoll, egal bei welcher Sprache. Diese Einschränkung (100KB) ist meiner Meinung nach ein größeres Problem als die "nur" 1000N/s.

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.

 

@borg: Wozu tendiert ihr denn? Weiterhin zu C?

Morgens C, mittags Python und abends TinkerBASIC .