On Device Programming: C vs Python

[batti]

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?

[Nic]

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.

Aus dem Bauch heraus eher Phyton zu Beginn: damit alle etwas davon haben. Und um sich schnell in die Materie einzuarbeiten und Ergebnisse zu erzielen. Auch wenn die API in C so idiotensicher wie möglich wäre, ist C doch eher was für Gurus. Allerdings wäre es doch ein Ko für Phyton wenn die Performance weit unter der von C liege.

 

Ansonsten schließe ich mich dem Tenor an, die Beispiele in der Doku zu konkretisieren und ergänzen, insbesondere bei so anspruchsvollen Teilen wie z.B. das IMU. "Banale" Bricklets wie IO, Relay muss das nicht unbedingt sein.

Ansonsten vielleicht die Doku noch um Elektronik-Tips ergänzen, dazu ist das Defizit im Vergleich zu Programmier-Skills wesentlich größer.

[FabianB]

Wenn "nur" eins von beidem geht würde ich eher zu der On-Device API für C tendieren.

 

1. Bietet das in meinen Augen deutlich mehr Möglichkeiten, du sagst ja selber, dass man kein vollständiges Python unterstützen könnte.

2. Ist das für On-Device Anwendungen eher das typische/gewohnte. Leute, die aus dieser Ecke kämen, würden sich direkt heimischer fühlen.

 

 

Für die Python-Variante spricht, dass sie (wenn man Python beherrscht) für User einfacher ist. Das hängt in meinen Augen aber auch stark davon ab, wie genau die C-API realisiert werden würde. Wenn man gut angeleitet wird und die Benutzung sehr einfach ist, würde das den Python-Vorteil zunichte machen. Es hängt also wirklich von der Umsetzungsqualität der Dokumentation und Anleitung ab. In der Hinsicht vertraue ich euch aber, das habt ihr bisher ja auch gut gekonnt.

-> C-API

 

 

 

 

Vielleicht hilft hier eine Abstimmung weiter? Dafür wäre es aber gut, je ein Beispiel zu bekommen, wie das in etwa aussehen würde/könnte.

[benatweb]

Ihr hattet doch mal gesagt, ihr würdet bei der On-Device Geschichte erstmal abwarten wollen, bis das Arduino-Team den Due fertig hat, weil der nen ähnlichen ARM-Core hätte und ihr evtl. von deren Arbeit was übernehmen könntet. Mittlerweile ist der Due ja draußen, habt ihr euch das nochmal angeschaut oder ist das ne Sackgasse?

 

 

Vielleicht hilft hier eine Abstimmung weiter? Dafür wäre es aber gut, je ein Beispiel zu bekommen, wie das in etwa aussehen würde/könnte.

 

+1

 

Persöhnlich würde ich auch eher zu C tendieren, das "passt" einfach mehr zu On-Device. Allerdings sollte es dann leicht verständlich aufgebaut und gut dokumentiert sein (Arduino ist da ein gutes Vorbild). Wenn es allerdings "kryptisches C" werden sollte, dürfte das viele abschrecken.

 

Edit:

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.

Würde das dann bedeuten, das wir quasi unsere eigene Firmware schreiben würden? Also eure als Basis nehmen, unser Programm da reinbauen und dann flashen? Das fände ich dann nicht so gut. Das würde ja unter anderem Firmware-Updates richtig kompliziert machen.

Da würde mir dann der python-Ansatz (mal unabhängig von der Programmiersprache) besser gefallen, eigenes Programm schreiben, auf den Brick spielen und das existiert da unabhängig von der eigentlichen Firmware und wird von der nur ausgeführt. Hab ich das so richtig verstanden?

[Bralph]

Ich würde auch zur C-API tendieren. Auch in Hinblick auf eure Zielgruppe Industrie.

Was mir etwas an der Homepage fehlt ist eine Beschreibung zur Lizenzierung. So direkt habe ich dazu nichts gefunden. Ihr sprecht zwar von „open source hardware“, aber das sagt nichts über die Lizenzierung aus. Klar in den Tiefen der Schaltpläne findet man die CERN OHL 1.1 Lizenz (auf der Homepage wird das bis auf zwei Pressemittelungen nicht erwähnt). Die Frage bleibt ob ihr auch andere Lizenzmodelle anbietet: z.B. was würde es kosten, das Design weiterzuentwickeln und kommerziell zu vertreiben? Für die Industrie mit dem ganzen Prototypenbau sicherlich ein interessanter Punkt.

 

[Plenz]

Auch wenn die API in C so idiotensicher wie möglich wäre, ist C doch eher was für Gurus.

Kommt drauf an. Wenn ich den Quellcode für die Firmware des IO4 sehe, wird mir schwindelig. All die verschiedenen Arten von Variablen, die direkt oder referenziert an Subroutinen übergeben werden usw., das ist bestimmt etwas für Gurus. Aber ich habe selbst schon DLLs in C geschrieben, dabei ging es um Manipulationen von Grafikbitmaps, und dafür reichten Bytes, Integer, Arrayzugriffe und die vier Grundrechenarten, das war wirklich nicht schwer.

 

Ich habe weiter oben die Geschwindigkeit erwähnt. Ein Wunsch von mir wäre es, mit dem IO4 ein Infrarot-Fernsteuersignal zu decodieren, dazu braucht man einige 10000 Abtastungen pro Sekunde. Ein Programm dafür wäre simpel, nur ein paar Schleifen und Zähler. So etwas habe ich auch schon mal in Z80 Assembler programmiert, und mit C kann das auch nicht schwieriger sein.

 

Ich vermute, je maschinennäher der Compiler arbeitet, desto niedriger ist der Level der notwendigen C-Kenntnisse, oder?

[borg]

Ich hab die beiden Threads mal getrennt, ich fand bei dem anderen Thread die Diskussion um die Kits sehr interessant. Die sind dann ein bisschen untergegangen.

 

Zur genaueren Erklärung der C vs Python Geschichte: Es gäbe die Möglichkeit einen minimalen Python Interpreter auf die Bricks zu bringen (http://code.google.com/p/python-on-a-chip/). Da hätte man dann die API unserer Bindings zur Verfügung und keinen direkten Zugriff auf die Hardware. Eine alternative zu Python wäre LUA (http://www.eluaproject.net/). Es wäre dort so, das weiterhin "nur" 1000 Nachrichten pro Sekunde verarbeitet werden, als würde man über USB arbeiten.

 

Bei einer C API müssten wir im Prinzip die existierende Firmware wegwerfen und neu anfangen. Der ganze interne Aufbau ist zu sehr auf die USB Abfragerate getrimmt. Das wäre ein riesiger Aufwand für uns. Desweiteren wird es natürlich immer so sein, dass man sich einen C Compiler installieren muss und den Code Compilieren und draufflashen usw, wie bei Arduino eben.

[benatweb]

Was wäre in dem Fall denn mit dem bisherigen Modell über USB und Bindings, das klingt ja so, als würde das dann wegfallen?

[borg]

Ne, das können wir natürlich nicht wegfallen lassen. Wir müssten dann zwei unterschiedliche Firmwares unterstützen. Man würde natürlich die Low-Level-Ansteuerung von Motoren und ähnliches abstrahieren damit das nicht alles doppelt implementiert ist.

[Loetkolben]

Hmmm,

 

wie ich das sehe geht es zwischen C und Python hin und her. Eine Abstimmung laege nahe, aber ich moechte gerne folgendes zu bedenken geben: Man sollte bei den obigen Meinungen oder bei einer Abstimmung das Know How der jeweiligen User betrachten und auf keinen Fall vergessen fuer wen die "On Device Programmierung" gedacht ist.

Wenn man auf einem D&W Parkplatz nach Auspuffanlagen fragt, koennen die wahrscheinlich nicht gross genug sein, aber will man wirklich den "Tieferleger" fragen?

 

Vielleicht vervollstaendigt Tinkerforge diese Aussage:

 

"Wir moechten die On Device Programmierung fuer folgende Zielgruppe einfuehren. Die ... Was halten die Experten/Forumsteilnehmer davon?"

 

Ich persoenlich halte ein erfolgreiches Produkt fuer wichtiger als ein Ding was alles kann, aber sich niemand (nur wenige) damit beschaeftigt. Machbar ist sicherlich vieles und mein Wunschzettel ist auch gross. 

 

Zum Thema zurueck: Ich denke Python waere der richtige Weg weil er mehr User ansprechen wuerde und somit das Produkt erfolgreicher macht. - Vielleicht kann man damit auch eine ganz andere Gruppe ansprechen als Arduino User.

 

 

Der Loetkolben

[AuronX]

Ich denke Python würde eher dem TF-Gedanken entsprechen. Zumindest meiner Idee dieses Gedanken.

 

Würde ich in C auf Hardware programmieren wollen würde ich wohl gar kein TF nutzen. Aber vielleicht übersehe ich da auch andere Vorteile von TF gegenüber Arduino.

 

Wegen Firmware auf 1000 Messages/s: Ist das nicht auch für WiFi und Ethernet-Extension ein Problem?

Ich denke da würde icha uch über beide Protokolle mehr als 1000 Nachrichten pro Sekunde kriegen. Ist also kein reines On-Device-Problem oder?

[Nic]

C ist sicher der Königsweg, aber ich habe neben Familie und Beruf kaum die Nerven und Zeit mich um so eine anspruchsvolle Hochsprache für die hardwarenahe Programm. rumzuschlagen. Tinkerforge Sachen empfehlen sich für das schnelle Prototyping, da ist eine relativ einfache verständliche Umgeb, wie durch Phyton eine vernünftige Ergänzung.

 

...einen minimalen Python Interpreter auf die Bricks zu bringen (http://code.google.com/p/python-on-a-chip/).

Ich sehe dort die letzte News ist datiert Ende Sep.2011, wird das Project überhaupt noch weiter gepflegt ?

 

Die "Hardcore" Entwicklung in C ist doch jetzt schon möglich wenn auch mit viel Aufwand und Pionierarbeit.

Es gäbe die Möglichkeit einen minimalen Python Interpreter auf die Bricks zu bringen (http://code.google.com/p/python-on-a-chip/). Da hätte man dann die API unserer Bindings zur Verfügung und keinen direkten Zugriff auf die Hardware.

Was heißt das jetzt genau: ist der BrickD damit in der BrickCPU ? Ich hätte keinen "direkten" Zugriff auf die Hardwarepins, aber wie würde ein Direktanschluss und -auswertung zB. des Joystick am Stepper aussehen ?

[AuronX]

Genau so habe ich das verstanden.

Du könntest das selbe Skript gegen einen brickd laufen lassen, weil die API identisch ist:

Da hätte man dann die API unserer Bindings zur Verfügung und keinen direkten Zugriff auf die Hardware.

 

Es macht also bei der Entwicklung keinen Unterschied (bis auf den eingeschränkten Interpreter) wo dein Skript läuft.

 

Zur Erklärung: Eingeschränkter Interpreter heißt am Ende, dass dir irgendwann doch auf die Füße fallen wird, dass das Teil nicht so viel kann. Weil du an deinem Rechner Sachen machen kannst, die dann da nicht gehen.

Wahrscheinlich wird dein Skript auch nicht unendlich groß sein dürfen. Halt die typischen Einschränkungen auf so kleinen Geräten ^^

[Nic]

Wahrscheinlich wird dein Skript auch nicht unendlich groß sein dürfen

Das ist in der Tat schnell erreicht, dann sollte ein Parallel-Betrieb von embedded und Host-PC BrickD möglich bleiben.

[rifmetroid]

Ich werfe mal noch eine weitere Idee in dem Raum und zwar ein Speicher Brick, welches das "Programm" (ob nun von C oder Python) beinhaltet. Der Master merkt dann einfach, dass so ein Brick da ist und führt dann den Code im Speicherbrick aus. Da hätte man dann nicht so die Platzprobleme und könnte mit Python vielleicht etwas mehr anfangen. Vielleicht ist das auch gar nicht möglich, aber ich hatte mit nem Kollegen mal über die Idee nachgedacht und wir fanden das eigentlich ganz gut .

 

Ich wäre aber auch eher für C, da es mir einfach besser liegt und man da evtl. nicht so schnell in Beschränkungen läuft wie bei Python.

 

Gruß

rif

[Plenz]

Ich werfe mal noch eine weitere Idee in dem Raum und zwar ein Speicher Brick, welches das "Programm" (ob nun von C oder Python) beinhaltet. Der Master merkt dann einfach, dass so ein Brick da ist und führt dann den Code im Speicherbrick aus.

Die Idee gefällt mir sehr gut. Aber ich möchte mal zwei Beispiele bringen, die ich gern realisieren würde, aber mit den jetzigen Möglichkeiten nicht kann:

 

1.) Kleine Zusatzroutine zur Firmware. Das Steuerprogramm in meinem PC ruft einen userdefinierbaren Befehl auf

Function BrickletIO4.Userdefined(Integer) As Integer

und dort kann ich eine Routine unterbringen, die Ein- und/oder Ausgänge steuert und ein Ergebnis zurück gibt, z.B. die erkannte Folge von Nullen und Einsen aus dem Signal einer IR-Fernbedienung

 

2.) Eine Stand-Alone-Anwendung ohne PC, tragbar mit geringem Stromverbrauch. An einem Schrittmotor ist ein Zeiger befestigt, der mir in meinem Segelboot die Richtung zum nächsten Koordinatenpunkt meiner geplanten Route anzeigt, gesteuert vom GPS-Bricklet. Sinn der Sache: eine Orientierungshilfe, die man auch erkennen kann, wenn die Sonne blendet und/oder die Schutzhülle des Navi durch zu viele Salzwasserspritzer quasi undurchsichtig geworden ist.

 

OK, das hat jetzt weniger mit der Frage "C vs Python" zu tun, aber mich interessiert, wie weit TF diese beiden Fälle überhaupt für realisierbar und in die Firmware integrierbar hält.

 

[jan]

Auch wenn ich kein C hinbekomme bin ich für C. Es ist dann nun mal Hardwarnahe, also sollte auch eine Sprache dafür verwendet werden.

[ArcaneDraconum]

Ich würde mich auch gerne für Python aussprechen, weil damit meine Hardware (Brain) besser zurecht kommt.

[raphael_vogel]

Definitiv +1 für Python.

Habe extra TF gewählt da hier mehr von der Hardware abstrahiert wird und mehrere Bindings angeboten werden. Da ich von Java komme müsste ich zwar auch umlernen, aber wegen des Zeitaufwands würde ich eher Python als C lernen.

Sonst kann ich auch gleich Arduino nehmen.

 

Aber die Idee mit dem Speicherchip gefällt mir am Besten!

[FabianB]

Das mit dem Speicherchip fänd ich auch ziemlich gut, auch, wenn mir nicht so 100%ig klar ist, wie genau der funktionieren soll.

 

Bzgl. Python oder C: Für mich hängt es maßgeblich davon ab, wie hardwarenah das Schreiben einer eigenen Firmware wirklich wäre. Wenn es einen Lösungsweg gäbe, der so aussieht, dass man quasi ein fertiges Firmware-Grundgerüst nimmt und nur noch relativ abstrahiert, d.h. mit vorgefertigten Methoden wie wir sie schon kennen, die Programmlogik implementieren muss, dann fänd ich den besser. Deswegen hatte ich nach einem Beispiel gefragt, wie das in etwa aussehen würde.

Der Knackpunkt ist wirklich, wie einfach das zu benutzen/programmieren ist. Das posten ja auch viele andere hier. Wenn man quasi nur in der Lage sein muss, ne for-Schleife und ne if-Verzweigung in C hinzubekommen und die TF-typischen Funktionen aufzurufen, dann kann das vermutlich jeder ohne Einarbeitung in C hinbekommen.

 

 

Um das vernünftig beurteilen zu können, wäre es echt gut, das genaue Konzept und die Anwendungsweise zu kennen.

 

[Equinox]

Hallo,

 

ich schließe mich JavaLaurence im englischen Thread an. Ich würde es auch bevorzugen, wenn man in Java auf den Bricks/Bricklets programmieren könnte. Wäre das soviel aufwändiger?

Falls das nicht machbar ist, dann bin ich für Python.

[The_Real_Black]

Ich bin für C es ist einfacher und hardwarenaher.

Java ist auf Bricks vermutlich nicht möglich, da man dafür JRE benötigt dass würde die Grenzen der Bricks massiv sprengen...

C lässt sich auch prima im Assembler Code optimieren mit anderen Sprachen ist dies nicht möglich.

[AuronX]

Ich glaube ich möchte mcih doch deutlicher als bisher positionieren:

 

Warum soll C notwendig sein?

In C auf den Bricks programmieren kann man schon heute.

Also wo soll da am Ende der Unterschied zum Status quo sein? Eine schönere API? Vermutlich nicht, es ist ja trotzdem C.

 

Ein immer wiederkehrender Wunsch im Forum war es aber sich "einfach" den Host-Rechner zu sparen. Oft auch in Verbindung mit einem Thread-ersteller, der vermutlich einfach besser kein C schreiben sollte/möchte.

 

Wenn man schon den Komfort für das programmieren auf dem Brick verbessern will, dann sollte man auch den konsequenten Schritt zu einer hohen Sprache gehen.

 

@Real_Black: Warum ist C einfacher?

 

C lässt sich auch prima im Assembler Code optimieren mit anderen Sprachen ist dies nicht möglich.

 

Hast du wirklich vor das zu tun?

 

@Java: Das geht schon, braucht aber extra Hardware.

[The_Real_Black]

@AuronX: Es ist primitiver und hat keine Objekte, daher müssen keine Zugriffsrechte oder andere objektorientierte Konzepte berücksichtigt werden. Mit kleinen flachen Strukturen sollte der Overhead geringer sein. Mit objektorientierten Sprachen zieht man sich immer einen Mehraufwand zu.

@"Assembler": Ja ich würde, wenn ich "On Device" entwickle, auf jedenfall auch in Assember optimieren oder gleich in Assembler entwickeln. Nur damit kann man alle Funktionen der Bricks direkt nutzen und hardwarenaher wird man nicht kommen.

 

@"Jazelle": Wie klein ist sowas? Ein paar Bilder sehen aus als wäre der Chip größer als ein Brick...

[AuronX]

Mehraufwand auf der Seite von TF: ja

Mehraufwand auf der Seite des Kunden: im Gegenteil, das Entwickeln ist C ist einfach mal schwerer und macht weniger Spaß (aber das könnte auch Geschmacksfrage sein).

 

Wenn du aber eh mit dem Gedanken spielst in Assembler zu entwickeln eine andere Frage: Welche Vorteile/Features erhoffst du dir von einer anderen API als der die bereits verfügbar ist? (Da ich wirklich keine Ahnung habe ist die Frage ernstgemeint ) Ich würde intuitiv denken, dass es dir reicht deine (vollständig) eigene Firmware aufs Brick zu bügeln.