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?

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.

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.

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.

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?

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.

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

Danke für die Erklärung, das war sehr hilfreich. Ich habe noch keine Meinung dazu, ob das Scheduling geändert werden sollte. Aber ich bin immer überzeugter davon, dass ihr bei dieser Firmware bleiben solltet. Das Verkauf/Leistung Verhältnis würde einen hohen Aufwand nicht rechtfertigen. Holt einfach das Beste und einfachste aus den gegebenen Möglichkeiten raus. Der Knackpunkt für den Erfolg der OnDevice API ist eh, ob sie einfach zu verwenden ist.

Das erste haben die anderen schon beantwortet. Den Rest deiner Aussage sehe ich ebenso und hatte das ja auch schon angedeutet: Ich bin auch der Meinung, dass man zuerst die Mehrheit bedienen sollte. Es ist in der Summe halt nur eine Niesche, in der man was schnelleres braucht. Deswegen bin ich halt dafür, eine einfache C-API zu machen:

Die Tendenz scheint mir so langsam doch in Richtung C-API zu gehen. Der zitierte Vorschlag von Borg klingt ja nach einem guten Kompromiss: Nicht super-schnell aber auch nicht so hardware-nah. C-API schnell realisierbar für TF, keine extra Hardware, wenn die API gut wird wirds leicht anwendbar, die Umsetzung wird nicht hardwarenah sondern "high-level-on-device", es gibt keine Einschränkungen wie bei der (leicht) eingeschränkten Python-Lösung. Sehe ich das so richtig? @Borg: Könntest du uns eine Vorstellung davon geben, wie viele Nachrichten/Sekunde "Grundrauschen" sind? Gibts überhaupt welches? Damit meine ich, wie viele Nachrichten bei einem vollen Stack (8 Master, 32 Bricklets) bei hergestellter Verbindung aber ohne ausgeführten weiteren Code pro Sekunde laufen. Damit man eine Einschätzung hat, wie viele Nachrichten man pro Sekunde noch "frei" hat. Das wäre unabhängig von dieser Diskussion interessant. In der Zwischenzeit kam das hier rein: Guter Vorschlag. Ich würde damit gerne mal eine CNC-Fräse selber bauen. Einziger Grund für mich das on-device zu regeln wäre, dass ich mir davon eine höhere Genauigkeit verspreche. Ursprünglich hatte ich mal vor, einen Quadrocopter selber zu bauen. Da wäre es auch gut, auf einen PC verzichten zu können. Dafür sollten allerdings die 1000 N/s noch so gerade ausreichen (weiß ich aber nicht so genau). Für alle anderen Anwendungen wie KLimaüberwachung mit Temperature, Humidity LCD etc. wäre standalone auch super, weil man sich einfach den PC sparen kann und das mobiler ist. Für solche Sachen reichen aber die 1000N/s locker aus. Dafür wäre die leichte Anwendbarkeit das wichtigste Kriterium. Die Frage ist, welcher Anwendungstyp häufiger genutzt wird. Ich vermute, unterm Strich werden die einfachen Sachen häufiger umgesetzt.

Stimmt, das habe ich nicht bedacht. Dann muss dieser Vorgang ausgelagert bleiben und jeder verwendet die Software, die er gewohnt ist. Eine entsprechende Doku muss den Vorgang dann erklären. Insgesamt bleibe ich aber erstmal bei dem Grundprinzip. :-)

Die "Entwicklungsumgebung" würde ich in den Brick-Viewer einbauen, die muss auch nicht wirklich mehr können als ein Textfeld zur Aufnahme des Quellcodes anbieten, automatisch die aktuellsten Firmware-Quellcodes von euch runterladen, das zusammenpacken und flashen. Den Quellcode schreiben kann dann jeder in seiner gewohnten IDE, das Ergebnis dann per Copy-Paste in das Textfeld. Zur Nachrichtengeschwindigkeit: An die anderen, was stellt ihr euch denn als erstrebenswerte Geschwindigkeit vor? Eine komplett neue Firmware zu schreiben wäre aufwändig, aber würde sich das unterm Strich nicht lohnen?

Wäre es nicht möglich, die Anzahl der Nachrichten/Sekunde anzuheben, wenn erkannt wird, dass der Stack standalone läuft? Wäre es nicht möglich, den Geschwindigkeitsbeschränkenden Faktor der Firmware redundant auszulegen, so dass jeweils die geeignete Variante (Am PC -> langsam, standalone -> schnell) verwendet wird? Wenn nicht, hätte dieser Kompromiss einen bitteren Nachgeschmack. Soweit ich das sehe, ist eine höhere Nachrichtenrate vor allem für Implementierungen relevant, die genauer arbeiten sollen (CNC-Fräsen im Eigenbau oder sowas) Da kommt man ab einer gewissen Komplexität des Stacks recht schnell an die 1000N/s. Es sollte ja gerade einer der Vorteile der On-Device-Programmierung sein, eine höhere Geschwindigkeit/Genauigkeit zu erreichen. ICh denke auch, dass diese Variante für euch am schnellsten zu realisieren ist. Allerdings würde ich nicht unterschätzen, dass es da viel Detailaufwand geben dürfte, um das auch wirklich Nutzerfreundlich zu gestalten. MAn muss soweit es irgendwie sinnvoll realisierbar ist jede Auseinandersetzung mit der Hardware vermeiden.

Ich fasse die Problematik zur Übersicht nochmal aus meiner Sicht zusammen. Ich denke, die für uns wichtigen Aspekte bei der On-Device-Programmierung sind: Kein PC muss angeschlossen sein Höhere Genauigkeit und geringere Verzögerung in den Programmen möglich Diese beiden Ziele sollen erreicht werden unter Einhaltung dieser Bedingungen: Extrem leichte Verwendbarkeit/Programmierbarkeit Keine/Geringe Zusatzkosten für Extra-Hardware Kompatibilität zu anderen bekannten Techniken (außerdem soll das Rad nicht neu erfunden werden) Die Lösungsvorschläge: Hochsprache wie Java etc. (Vorteil: Einfach anzuwenden, Kompatibilität; Nachteile: Wahrscheinlich Hardwarekosten, z.T ungenauer bzw. langsamer als C) Verbesserte API in C: (Nachteil: Schwieriger umzusetzen für Einsteiger; Vorteile: Keine Zusatzkosten, Sonst sind alle weiteren Zielsetzungen erfüllt) ...? Welche Lösungen/Vor- oder Nachteile habe ich vergessen? Bitte ergänzen. Wenn ich mir den Stand der Dinge so ansehe komme ich wieder zur These eines meiner älteren Posts: Man sollte versuchen, die Vorteile von C zu nutzen und den Nachteil der schwierigeren Anwendbarkeit durch eine geeignete Umsetzung ausmerzen. Für mich sähe diese Umsetzung so aus: Man bekommt eine API bzw. eine Art Framework in C, dass dem Programmierer die bekannten Funktionen in der Einfachheit der Hochsprachen-APIs zur Verfügung stellt. Der Benutzer soll nur noch auf Hochsprachen-Niveau programmieren müssen und sich nicht mehr im geringsten mit Hardware-naher Programmierung befassen müssen. Die notwendigen Implementierungen sind bereits alle in der Firmware enthalten. Der Programmierer programmiert nur noch im Stile der Arduino-Sprache, die Benutzungsprinzipien von Objektorientierung sollen erhalten bleiben. Das fertige Programm kann man per Copy-Paste in eine markierte Stelle in der Firmware kopieren und flasht diese auf ein Brick. DIeser Vorgang könnte durch eine eigens angefertigte Software von TF stark vereinfach werden, sodass man nur noch seinen Quellcode in ein Textfeld kopiert und diese Software alles weitere übernimmt, sodass man nur noch den fertig lauffähigen Stack vom Rechner abziehen muss und der loslegen kann. Diese Software kann einen auch beim Eintragen der notwendigen UIDs unterstützen etc. Abgerundet werden müsste das durch eine knackige Dokumentation. Ich bin der Ansicht, dass das Programmieren in der Arduino-Sprache für jeden Hobby-Programmierer auf Anhieb möglich ist, vor allem, wenn alle Funktionen zum Benutzen der Bricks/Bricklets so gestaltet sind, wie sie z.B. bei Java aussehen. Dieser Lösungsansatz verbinden in meinen Augen alle Vorteile. Keine Extrakosten, einfache Anwendbarkeit, hohe Geschwindigkeit... Ist verständlich geworden, wie ich mir das vorstelle? Wie seht ihr das? Was spricht dagegen? Technisch halte ich das für umsetzbar, seht ihr Schwierigkeiten? EDIT: Ich meinte nicht, dass man wirklich die Arduino-Sprache verwenden MUSS. Man kann auch bei C/C++ bleiben. Nur muss dass dann so vereinfacht anzuwenden sein, dass es so leicht ist, wie das Programmieren mit der Arduino-Sprache. EDIT 2: Das könnte auch so gestaltet sein, dass es die aktuelle Firmware ergänzt, man also nicht zwei verschieden Firmwares parallel haben muss. Die Firmware muss beim Starten halt erkennen, ob ein PC mit ihr kommuniziert oder ob sie standalone läuft.

Das mit den Bildern würde ich so lassen. Einziger wirklicher Kritikpunkt für mich ist der bereits genannte, den ich nochmal hervorheben möchte. Das Argument mit der Teamseite hatte ich ja auch schonmal gebracht und dabei bleibe ich noch immer. Eine Teamseite wäre schön.

Ja gefällt mir auch gut. Cool, dass ihr die Ansprechadresse für Business-Kunden eingerichtet habt. Einzige Sache, die mir aufgefallen ist: Das Video fand ich schon sehr aussagekräftig. Vielleicht könnte man das (oder eine neue Auflage) in "Was ist Tinkerforge" integrieren?

Freut mich, dass es geklappt hat. Zu Eclipse: Da der Pi ja insgesamt relativ schwach auf der BRust ist, würde ich zu was schlankerem greifen. Ich würde da persönlich zu Texteditor mit Syntax-Highlighting etc und Compiler greifen, statt zu einer kompletten IDE. Aber das ist natürlich Geschackssache. Vieleicht kann hier wer anderes eine schlanke IDE empfehlen?

Das finde ich mal ein echt gutes Feature. Darauf sollte unbedingt von TF verwiesen werden. Es werden bestimmt einige zu schätzen wissen, dass man Standard-Monitoring Software mit der Aufgabe betrauen kann.

Hallo The_Real_Black, Problem A: Ich gehe mal ganz schwer davon aus, dass du die folgende Seite schon kennst. Falls nicht, wirst du da schon einen Hinweis bekommen zu Tomcat: http://wiki.ubuntuusers.de/Tomcat Das ist zwar für Ubuntu geschrieben, kann aber analog für Raspbian übernommen werden. Das starten als root (siehe Link) ist nicht ratsam. Wie man das Starten einrichtet, wird auch beschrieben. Falls du das schon kennst und/oder es nicht funktioniert, poste am besten noch ein paar Details dazu, dann versuche ich gerne, im Detail zu helfen. Problem B: Für Eclipse solltest du zuerst das hier ausführen: sudo apt-get update Und es anschließend nochmal versuchen mit sudo apt-get install eclipse Eigentlich sollte er es danach korrekt finden. Falls nicht: sudo apt-get install gcj-jre Anschließend kannst du dir Eclipse von der offiziellen Webseite runterladen: https://www.eclipse.org/downloads/index.php?osType=linux Da suchst du dir die gewünschte Version aus und kopierst dir den Download-Link. Anschließend kannst du auf dem PI mit wget http:derdownloadlink.com/usw die entsprechende Datei runterladen. Dann nur noch entpacken, ausführbar machen und ausführen. FAlls du dabei Hilfe brauchst, sag bescheid. Die "anderen" Eclipse-Pakete a la eclipse-irgendwas sind keine anderen Versionen von Eclipse, sondern Pakete, die zu Eclipse dazugehören und/oder es erweitern (je nach Paket). Wenn du sudo apt-get install eclipse ausführst, dann wird dir eine ewig lange Liste mit zu installierenden Paketen angegeben. Du kannst das einfach bestätigen, du wirst sie brauchen. Aber allgemein finde ich es nicht die beste Idee, Eclipse auf dem PI zu installieren. Warum willst du dir das antun? Viel Erfolg

Nur, um das nochmal ein bisschen deutlicher zu machen: Ich denke, dass das aktuell angebotene Education-Kit nicht (wie beworben) optimal ist für Schulen etc. In der Form ist es kaum im Unterricht einzusetzen. Deswegen mein Einwand.

Ah, auch ein Mensch... wie überaschend Ok, das Bild kannte ich noch nicht. Erfolgreich gestalkt

Das kenne ich doch. Und die beiden sind ja auch in ihrem Video zu sehen. Es geht mir auch weniger darum, dass ICH Gesichter sehe (obwohl es ja schon mal interessant wäre, den mysteriösen Photron zu demystifizieren ). Ich finde es bei kleinen Firmen immer sympathisch, wenn das Team kurz vorgestellt wird. Und wenn man eh eine neue Webseite gestaltet... Aber das ist natürlich eine unwichtige Sache. Wichtiger ist der Rest

Ok, dann hier zurück zur Webseite und den Kits. Ich befürchte, dass sich die Webseite schwer an die Bedürfnisse der Industrie anpassen lässt. Ihr sagtet ja selbst schon, dass die das z.T. gar nicht öffentlich machen wollen, dass sie mit euren Produkten arbeiten. Das wird ja weiter so bleiben, für diese Zielgruppe ist deswegen eher ein schneller und qualifizierter Support hinter den Kulissen, sprich per Mail etc. wichtiger. Ihr könntet auf der neuen Webseite aber darauf verweisen, dass ihr für entsprechende Kunden einen derartigen Service anbietet, damit könntet ihr vielleicht für mehr Firmen interessant werden. Vielleicht könnte man für diese Zielgruppe ein extra Webformular o.ä. zum Mailversand anbieten, in das man auch die Rechnungsnummer der letzten Bestellung eintragen muss (um sich als Firmenkunde zu identifizieren). Hauptsache es wird deutlich: Für derartige Kunden gibt es schnellen, nichtöffentlichen und qualifizierten Support (diese Kunden setzen oft ungern auf Communities). Als weitere Ergänzung fänd ich persönlich schön, wenn es auf der neuen Webseite eine Sparte "Team" gibt, wo man sieht, wer da hintersteckt. Falls ihr Interesse daran habt, ein Kit für Schulen anzubieten, dann wäre ich bereit, daran mitzuarbeiten. Für Lehrer ist neben der günstigen Anschaffung wichtig, dass sie sofort sehen, wie sie das in den Unterricht integrieren können und wie das zum Lehrplan passt. Außerdem sollte es dazu dann eine Sammlung von Anwendungsszenarios und Beispielaufgaben/Arbeitsmaterialien geben, die den Lehrern die Arbeit erleichtern. Schreibt mir bei Bedarf eine Mail oder so.

Hab gerade nochmal deine Bilder angesehen. Ich glaube, dass es hilfreich sein könnte, den y-/z-Achsen Träger noch ein bisschen zu modifizieren. Der ist unten ja nur an die Kopfenden des Trägerbrettes angeschraubt. Ich würde da versuchen, noch eine weitere Querverbindung einzubauen und/oder Winkel ergänzen, um eine bessere Verwindungssteifigkeit zu bekommen. Vielleicht erkenne ich das auf deinen Bildern falsch, aber das sieht für mich wie eine Schwachstelle aus. Auch, wenn man "nur" Holz bearbeitet, sind die Querkräfte recht groß. Als Fräse sollen wohl die Geräte von Kress ziemlich gut sein. Die haben wohl auch so einen Euro-Hals (oder wie auch immer das heißt), der in die Standard-Halterungen passt. Ich habe gesehen, dass es in der aktuellen c't Hardware-Hacks um CNC-Fräsen im Eigenbau geht. Vielleicht ist das ja interessant für dich.

Ich mache hier mal einen Sammelthread auf, da mit der Zeit bestimmt noch eine Menge weiterer Projekte rund um den Raspberry Pi vorgestellt werden, die für Bastler interessant sind. Diese lustige Geschichte habe ich gerade gefunden: http://www.golem.de/news/selbstbauprojekt-raspberry-pi-als-mininotebook-mit-riesigem-akku-1303-97972.html Vom Konzept her könnte man so was in der Art auch mal mit TF-Produkten kombinieren.