borg

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.

Das ist so eine Geschichte für sich. Wir haben einen Prototypen hier, der leider Fehler im Layout hat. In der Zwischenzeit hat Maxbotix aber auch Ultraschallentfernungsmesser rausgebracht die direkt I2C sprechen (der Prototyp ist für eine analoge Version): http://www.lipoly.de/index.php?main_page=product_info&products_id=234792. Das wäre natürlich eigentlich besser, da wir keine Ungenauigkeit durch unterschiedliche Kabellängen reinbringen. Daher müssen wir dort eigentlich mit einem neuen Prototypen anfangen . Damit sich das ganze überhaupt für uns lohnt müssen wir mit unserer üblichen 1000er Stückzahl rechnen, was bei den Sensoren ganz schön teuer ist. Vor allem weil es da ja wieder unterschiedliche Entfernungen gibt, wodurch man noch nicht mal eine große Stückzahl pro Sensor abnimmt. Das ist durchaus auch ein Grund warum andere Produkte die vielleicht nicht so kostenintensiv sind Vorrang bekommen haben. Mal blöd gefragt: Was dürfte so ein Sonic Range Bricklet inklusive Sensor denn kosten?

@cfranz: Danke für die Ausführungen . Dann werde ich auch mal ein bisschen aus dem Nähkästchen plaudern: Wir haben im Moment die Befürchtung, dass es unklar ist für wen unsere Produkte überhaupt geeignet sind. Exakt da soll die neue Homepage Abhilfe schaffen. Wir haben da drei Zielgruppen Identifiziert: Bastler Lehre/Ausbildung Industrie Von den Zielgruppen ist leider nur die erste hier im Forum vertreten. Beispiele für Lehre und Ausbildung sind Diplomarbeiten: http://www.youtube.com/watch?v=aRifcnxx5eQ und Unterrichtsmodule wie dieses hier: http://schuelerlabor.informatik.rwth-aachen.de/modul/das-haus-der-zukunft-hausautomation-mit-mikrocontrollern In der Industrie sind wir hauptsächlich für den Prototypenbau und die Forschung interessant. Eigentlich immer dann wenn etwas auf die Schnelle automatisiert werden muss. Da kann ich leider nicht so schrecklich viel zu schreiben, oft ist da eine Veröffentlichung unerwünscht. Beispiel: Ich denke das wir diese Zielgruppen und auch eine leichter verständliche allgemeine Konzeptbeschreibung auf der neuen Homepage gut untergebracht haben. Das nächste Problem was wir sehen, was du im Prinzip auch angesprochen hast: Jemand der unseren Kram benutzt muss extrem Kreativ sein. Verglichen mit Fischer- oder Lego Technik muss ich ganz genau wissen welches Problem ich eigentlich lösen will. Bei Arduino ist diese Kreativität nicht nötig, da es einfach tausende gut dokumentierte Projekte gibt an denen man sich orientieren kann. Um das zu umgehen haben wir vor auf dauer mehr Starterkits anzubieten. Als erstes (steht auch schon in der Timeline) wird es vermutlich ein Wetterstation Starterkit geben. Dafür wird es dann Source Code für die simpelste Anwendungen in allen Programmiersprachen geben die wir anbieten (in diesem Fall die Wetterdaten auf einem LCD20x4 Bricklet anzeigen) und Source Code für komplexere Anwendungen in jeweils geeigneten Programmiersprachen (z.B. anzeigen von Wetterdaten auf einer Homepage in PHP). Für diese ausführlicheren Starterkits wird es dann auf Dauer auch Gehäuse geben und eine professionellere Verpackung, vielleicht vergleichbar mit einem "Kosmos Experimentierkasten" (falls das jemanden etwas sagt). Diese Starterkits soll es dann auch außerhalb unseres Shops bei den großen "Online-Elektronikhändlern" zu kaufen geben. Das bedeutet dann auch gleichzeitig, dass der Preis evtl. ein bisschen höher liegt als man im ersten Moment erwarten würde. Die ganzen Projekte und der ganze Beispiel Source Code ist aber natürlich Open Source und online Verfügbar. Wodurch dann auch wenn man keines der Starterkits kauft eine Anschubkreativität freigesetzt werden kann . Was haltet ihr von dem Konzept?

Oh. Was hättest du denn erwartet? So wie ich die Terminologie sehe bieten Bricks einen Service mit einer definierten ABI (http://en.wikipedia.org/wiki/Application_binary_interface) und die Bindings (http://en.wikipedia.org/wiki/Language_binding) bieten eine API (http://en.wikipedia.org/wiki/Application_programming_interface) um mit einer bestimmten Programmiersprachen über die API mit der ABI mit dem Service kommunizieren zu können . Die Kombination aus Brickv, Brickd, Bindings für eine Programmiersprache und die dazu gehörende Dokumentation wäre dann ein SDK (http://de.wikipedia.org/wiki/Software_Development_Kit). Diese Diskussion hatten wir intern auch schonmal (welcher Name für die "Bindings" am besten ist). Wäre es verständlicher gewesen die Bindings einfach SDKs zu nennen?

Den IPCON_CALLBACK_DISCONNECTED könntest du provozieren indem du im laufenden Betrieb den Brick Daemon killst. Ansonsten tritt er z.B. auf wenn du die WIFI Extension benutzt und die Verbindung zum AP abbricht o.ä.

Wäre eine Überlegung wert. Ist 20cm eine gute Länge für ein kurzes Kabel? Was meinen die anderen dazu?

Die Möglichkeit besteht auch bei dem WIFI Modul, ja. Dort würde dann natürlich die von GainSpan vergebene MAC Adresse überschrieben.

Wir haben die folgenden 4096 Adressen gekauft: 40-D8-55-0A-AX-XX. Wir können die also nicht einfach beliebig vergeben . API mit der man die MAC Adresse ändern kann, können wir natürlich bieten.

Mysteriös. Andere Bricklet Kabel hast du schon getestet? Hat vielleicht einer der Bricklet Stecker einen Kurzschluss (wie hier: http://www.tinkerforge.com/doc/_images/bricklet_connector_short_circuit4.jpg )?

The hostname has to be set once and will work from then on (you can set it with the newest Brick Viewer version). You can restart the AP, thats no problem. It works the same as with the hostname of your Mac .