borg

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 .

Wäre es denn akzeptabel wenn weiterhin nur 1000 Nachrichten/Sekunde durchs System laufen? Weil das würde es bedeuten wenn die normale Firmware verwendet wird. Eine Lösung, die das bestehende System benutzt und wo in C programmiert wird wäre mit Abstand der geringste Aufwand für uns. Da könnte man einfach die C Bindings nehmen, das Backend austauschen durch ein direktes Schreiben in die internen Buffer und fertig .

If that is the goal, C is the only option. But i don't think that should be the goal. It is a pain to solder stuff to Bricks or Bricklets and why would we want to go the Arduino route? You said yourself that you didn't do anything with Arduino because of your lack in electronics experience .

Es gibt JVMs die klein genug sind für die Bricks, z.B. http://www.rtjcom.com/main.php?p=ovr Absolut ausgeschlossen ist java also nicht. Diese JVM braucht aber z.B. einen ClassLinker der vorher auf dem PC die Klassen "zusammenhämmert", um sich da das dynamische laden zu sparen. Dieser ist natürlich nur für Windows verfügbar... Die JVM benötigt von Hardware Seite aus eine Timer mit 5-20ms Intervall, was dann 50-200 Nachrichten pro Sekunde bedeuten würde... Ich befürchte das zu integrieren wäre eine Katastrophe. Ich denke es läuft auf zwei Möglichkeiten hinaus: Eine einfache interpretierte Sprache (die sich vernünftig in unser System integrieren lässt) oder C. Ersteres könnte der schon angesprochene Mini-Python-Interpreter sein oder vielleicht sogar ein kleines auf die Bricks abgestimmtes BASIC. Das könnte dann direkt ein Keyword für die Callbacks haben und für das hinzufügen von Callbacks usw. @The_Real_Black: Wir haben in Summe in allen Firmwares zusammen vielleicht 15 Zeilen Assembler geschrieben. Du brauchst definitiv kein Assembler um die Bricks zu programmieren. Ich würde auch bezweifeln, dass du ab einer gewissen Codegröße auch nur annähernd so gut optimieren kannst wie ein moderner C Compiler .

Klingt sinnvoll, ich schreibe es mir mal als TODO auf.

Wie könnte man denn einen "High-Level-Bastler" besser charakterisieren? Eigentlich wollen wir ja gerade Leute ansprechen die nicht den Lötkolben in die Hand nehmen wollen/müssen. Wenn wir für den Bastler eigens ein Bild machen lassen mit Bricks drauf, dann müssen auf die anderen Bilder IMO auch welche drauf (was natürlich nicht absolut ausgeschlossen ist). Alles nicht so einfach... .

Das ist in der Tat ein Überbleibsel aus dem Protokoll V1 Code, kann also gelöscht werden. Probleme kann das nicht machen, die Funktion wird nirgends aufgerufen . Wieviele Nachrichten sendest du denn an den RS485 Client? Vielleicht stauen sich die Nachrichten einfach im Brick Daemon auf?

Falls ihr tote Links findet oder Änderungsvorschläge fürs CSS habt o.ä.: Immer her damit.

Dann müssen wir die Schritte per I2C o.ä. abfragen und können dies wieder nur 1000x pro Sekunde tun (wie normalerweise üblich). Das reicht aber von der Frequenz her nicht um eine richtig gute PID Regelung der Motorgeschwindigkeit zu machen. Zusätzlich würde das natürlich auch Komplexität und Preis des Bricklets erhöhen.

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.

Mh, das ist nicht so einfach. Die Bindings werden ja generiert (hier ist das passende GIT dafür: https://github.com/Tinkerforge/generators). Du müsstest damit das funktioniert im ruby/ Unterverzeichnis immer einmal "generate_ruby_bindings.py" aufrufen, die frisch generierten Bindings liegen dann in ruby/bindings/

Die On Device Programming Diskussion hab ich mal hier hin verschoben: http://www.tinkerunity.org/forum/index.php/topic,1459.0.html

This topic has been moved to Allgemeine Diskussionen. [iurl]http://www.tinkerunity.org/forum/index.php?topic=1459.0[/iurl]

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.

Batti meinte glaube ich mit aufgeschraubter Kamera, damit man auf dem Foto sehen kann wie das funktioniert .

In theory that is possible, but... The patch loader needs to fit completely in the RAM for this to work, so it can't be too clever. Unfortunately small changes in the source code will result in big changes in the binary firmware if it is compiled with O3 by a modern C compiler. So i am not sure how much you could do with this approach . Another thing is: We would need to have two different procedures to flash the Bricks (you need to be able to flash the "normal" way, otherwise you couldn't rescue a Brick that has lost its firmware). I fear that the flashing process would then be even more confusing then it is already.

The config is saved on the EEPROM on the WIFI Extension. The configuration should still work after an upgrade of the Master Brick.

With the microcontroller we are using this is unfortunately not possible. We would either need to add 512kb of external flash or we would have to limit the firmware size to 256kb.

Der verlinkte Sensor hat eine Auflösung von 1cm auf 7,5m Messbereich. Ist also genauer und hat eine längere Distanz verglichen mit den Distance IR Sensoren. Vor allen bekommt man mit Ultraschall Sensoren viel stabilere Ergebnisse.

Die Einstellung kann ich gut nachvollziehen, aber ich kann ja bei Lego schon hergehen und das Feuerwehrauto umbauen und aufmotzen usw. Genauso ist es mit der Wetterstation, natürlich kann man eine fertige Wetterstation für einen Bruchteil des Preises kaufen, aber kann man die auch mit beliebigen Sensoren erweitern, mit WIFI oder RS485 ausstatten, die Daten online hochladen und ein Relay schalten was die Jalousie schließt wenn die Temperatur zu hoch wird? Die Kits stellen im Prinzip sicher, dass ein Projekt kein totaler Ausfall wird. Da der Minimalausbau des Projekts schonmal gemacht wurde und beschrieben ist wie man ihn erreicht.