borg

Have you played around with the convergence speed?

That depends on the speed of the board. If it has a really fast CPU this would probably be true, but it would also be very expensive .

Aver USB you can't reach 760µs for this, unfortunately. The polling frequency is 1khz, which means 1 message per ms.

Also wir sollen einen Arduino Due Klon machen? Ich glaube das passt nicht so in unser Konzept. Es geht ja bei uns gerade dadrum nicht löten zu müssen.

Flashen über Commandline ist definitiv sinnvoll, sollten wir auf Dauer anbieten. Zum Thema flashen über WIFI siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1440.0.html

Das wird ja über unser normales Nachrichtensystem gehen, also auch über WLAN/Ethernet. 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.

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

No worries, we just splitted the On Device Programming thread, since it degraded to a discussion about a "Linux Brick" (that can handle real Java/Python with standard library etc). I agree that a Super Master is no viable anymore when there are Linux boards for 35€ available.

Ich Kommentiere das Gezanke einfach mal nicht . Also ich ziehe folgenden Schluss aus den Anforderungen die ich bisher gesehen habe: Es handelt sich bei dem gewünschten "Super-Master Brick" in der Tat um ein Linux Brick. @Equinox: Das bedeutet unter anderem automatisch, dass wir ein Image über die SD Karte einspielen, wie bei allen kleinen Linux Boards üblich. Jetzt ist unser Linux Brick aber natürlich kein gewöhnliches Linux Board, wir wollen ja Sensoren auslesen, regeln und steuern. D.h. wir brauchen kein HDMI, Sound und diesen ganzen Schnickschnack (würde eh nicht auf 4x4cm passen). Bleibt eigentlich nur noch die Frage nach der Leistung. Das Linux Board von der Elektor läuft mit 180MHz, ist also eine echte Krücke ! Das wäre das absolute Minimum was man überhaupt noch mit Linux betreiben könnte. Damit würde sich z.B. mit hoher Wahrscheinlichkeit kein Quadcopter steuern lassen. Direkt per On Device mit C auf den Bricks ginge das aber sehr wahrscheinlich schon. Ist natürlich dann eine lustige Situation. Wenn wir jetzt mit der Leistung hoch gehen, in Richtung RPI oder darüber, dann gehen wir mit dem Verkaufspreis allerdings leider auch schnell weit über die 100€ hinaus. Die Frage die ich mich stelle: Gibt es da irgendwo ein passendes Maß an Leistung wo das Preis-/Leistungsverhältnis Sinn macht? Und macht das auch in 1,5 Jahren noch Sinn?

Unter einem Mini-Betriebssystem verstehen wir hier Windows/Mac OS/Linux/Solaris/Unix, richtig? Wenn nicht, was meinst du damit und was ist eine vollständige Java VM? Ich glaube nämlich nicht das es eine vollständige Java VM gibt (inklusive Standardbibliothek) die außerhalb dieser Betriebssysteme läuft. Warum ist steckbarer RAM wichtig?

Ich hab diesen Thread mal aus dem anderen herausgetrennt. Wir werden ein On Device Programming Interface für die existierenden Bricks anbieten. Da brauchen wir nicht drüber diskutieren. So ein Linux Brick oder Super-Master Brick ist natürlich auch eine Diskussion Wert. Anstatt darüber zu diskutieren ob es sinnvoller ist als ein On Device Programming Interface lasst uns darüber diskutieren wie so ein Super-Master Brick aussehen könnte. Also: Was sollte ein Super-Master Brick können? Was unterscheidet es von einem Raspberry PI? Und was darf es kosten?

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.

Ich kann mich da nur wiederholen: Die einzige "Hardwareerweiterung" die meiner Meinung nach Sinn machen würde, wäre ein Linux Brick (ein Raspberry PI im 4x4cm Format). Das wäre aber preislich leider nicht konkurrenzfähig. Vielleicht wenn wir irgendwann in 10000er oder 25000er Stückzahlen in China produzieren. Einen weiteren Master Brick der einfach mehr Flash/RAM hat bringt nicht genug Vorteile. Ein "komplettes Java" oder "komplettes Python" mit der ganzen Standardbibliothek wird da nie drauf laufen. Dafür benötigt es nunmal ein "echtes" Betriebssystem (also Linux/Mac/Windows). Damit sind wir dann wieder beim Linux Brick .

Zur Frage wofür On Device Programming sinnvoll ist: * autonome Wetterstation * autonome Robotersteuerung * So simple Sachen wie: Servo hochklappen wenn Spannung über einen Schwellwert geht etc * "Notfallbehandlung" wenn die USB/WIFI Verbindung weg ist * CNC Fräsen ansteuern (PC schickt sowas wie "Vektoren" die man auf dem Brick zwischenspeichert und in Echtzeit abarbeitet) Da gibt es schon viele Anwendungszwecke. Das meiste kann man natürlich auch über einen PC machen, klar. Dieser PC kann auch ein Raspberry PI sein . Unsere Argumentation wenn jemand On Device haben wollte war ja bisher ja auch immer "nimm doch das Raspberry PI/BeagleBoard". Nichtsdestotrotz kann ich auch den zusätzlichen Wunsch nach einem On Device Programming Interface nachvollziehen.

Wir haben uns schon richtig verstanden. RAM haben wir vielleicht 16KB über. Sprich alles was du in den RAM laden willst kannst du auch vorher in den Flash schieben anstatt auf externe Hardware . Wenn du meinst wir sollen zusätzlichen externen RAM anschließen: Das geht technisch nicht. Wie schon gesagt, zusätzliche externe Hardware für On Device Programming macht keinen Sinn. Wenn soviel Speicher benötigt wird kann man das Raspberry PI benutzen. Bisher wurde hier aber auch noch kein Projekt genannt was nicht auf den Master Brick passen würde .

Die Pinne die man braucht um Flash-Speicher anzuschließen liegen nicht auf dem Brick Stecker und sie sind auch einfach nicht über. Was soll das denn bringen? Dann kann ich ihn ja auch direkt in den Flash laden. Eine SD Karte ist nicht geeignet um dort Variablen abzulegen , da reden wir dann von Nachrichten pro Minute anstatt Nachrichten pro ms. 100KB ist mehr als genug um zum Mond und wieder zurück zu fliegen. Wieviele Zeilen C Code das sind kommt natürlich darauf an was in dem Code steht. Wenn ich den Code der im Moment auf dem Master Brick läuft diesbezüglich skaliere sind es 25000 Zeilen.

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

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. 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. 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. Morgens C, mittags Python und abends TinkerBASIC .

Sie wird nicht bis zum 1. April fertig sein, leider. Würde es Sinn machen wenn wir sie zum vorbestellen reinstellen, mit voraussichtlichem Lieferdatum in Woche ~18?

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 .

Die News war also schon im Forum angekommen bevor ich damit durch war das auf dem blog/twitter/facebook zu veröffentlichen. Ihr könnt es als eine Einweihungsfeier für die neue Homepage ansehen .

Da gibt es kein Grundrauschen. Das ist eigentlich auch ganz einfach: Es gibt Empfangsbuffer für die Schnittstellen (z.B. USB) und die werden alle einmal pro ms geleert. Und diese Taktrate von 1ms ist das Maximum was wir mit FreeRTOS sinnvoll erreichen können. D.h. wenn wir niedriger wollten müssten wir das Scheduling von FreeRTOS rauswerfen, dann müssten neue Firmwares her. Wir benutzen im Moment ein "echtes" Scheduling, d.h. Funktionen werden inkl. lokaler Variablen auf den Stack gepackt und später wieder geholt usw. Das Scheduling ist lediglich nicht preemptive, damit wir uns die ganzen mutexes sparen können. Ich könnte das durch Umsetzen einer Konstante preemptive machen. Wenn wir jetzt Dinge mit einer höheren Taktrate als 1KHz haben wollen, können wir einfach kein "echtes" Scheduling mehr verwenden (Der Verwaltungsaufwand wäre dann zu hoch). D.h. Anstatt einen Scheduler zu haben, hätte man eine Main-Loop die nacheinander alle benötigten Funktionen aufruft. Dadurch hat man dann den Scheduling Overhead nicht mehr. Gleichzeitig hat man dann aber im Prinzip keine lokalen Variablen mehr, die werden ja nicht mehr gesichert. D.h. man müsste ein Speichermanagement einbauen mit dem man dynamisch speicher allokieren/freigeben kann. Im ganzen heißt das, wir brauchen eine neue Firmware und der interne Aufbau muss anders sein. Ich hoffe das Erklärt grob warum es diese 1000 Nachrichten/Sek Grenze gibt und warum wir viel Arbeit haben wenn es mehr seien sollen.

Naja, ein Getter-Aufruf wird immer mindestens so lange brauchen wie die Pingzeit und die wird nie unter 1ms sein (bei Wi-Fi/Ethernet). Der Cortex-M3 hat ja einen Thumb2 Befehlssatz, in dem sind alle Befehle 16 Bit groß. Dadurch können immer zwei Befehle gleichzeitig geladen werden und dadurch dauert nahezu alles einen Takt. Auch die Sprungvorhersage. Das macht natürlich das Takte zählen einfach. Jo. Ich glaube wir müssen das mal anders angehen: Was wollt ihr denn Standalone mit den Bricks machen?

Sorry, aber das ist einfach keine Lösung. Dafür müsste der Brick Viewer dann die komplette GCC Toolchain mitbringen. Und wie soll das funktionieren? Man braucht ja schließlich ein paar Anläufe bis der C Code kompiliert. Wie bekommt der Nutzer denn die Compilefehler mitgeteilt? Einfach in einem Popup, ohne Syntax Highlighting ohne alles? Das ist doch ein Albtraum. Wer würde sowas benutzen wollen?

Ohne groß ins Detail zu gehen: Das ist nicht möglich. Mehr Nachrichten im kompletten System = Komplett neue Firmware. Mehr Nachrichten auf dem Brick, der Standalone läuft und 1000 Nachrichten/Sek im Rest des Systems (Stack Kommunikation etc) wäre noch denkbar. Ist halt die Frage wie weit man das treiben will. Die C API auf den Master Brick zu bringen wie oben angedeutet und zu dokumentieren geht schnell. Aber was ist mit der Entwicklungsumgebung? Welche soll man unter Windows nehmen? Und auf dem Mac? Wie kommt man an den Source Code? Master Brick Firmware und bricklib auf github clonen? Usw usw. Das fällt alles weg wenn wir eine interpretierte Sprache nehmen. Auf dem PC schreiben, auf das Brick laden und dort wirds interpretiert. Fertig .