borg

Wenn nicht ganz klar ist wo ein Bug hingehört, einfach irgendwo auf github posten. Ich kann den dann passend verschieben. Der Chibi Bug den du meinst wäre z.B. beim Master Brick Repository richtig gewesen (weil da die Software dafür liegt). Wenn du es im Chibi Extension Repository gemeldet hättest wäre es aber auch OK gewesen.

Ugh. Das hab ich befürchtet. Die IO16 wird vom Brick mit Spannung versorgt, wenn die Spannung über USB nicht ausreicht kann man dafür die Step-Down Powersupply verwenden. War beim Netzteil eine Strombegrenzung eingestellt? Funktioniert der Servo Brick noch wenn die IO16 nicht mehr dran ist?

An welcher Klemme mit dem Netzteil verbunden? Bzgl. Bootloader, siehe hier: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#flash-firmware-on-a-brick

Meldet sich der Brick denn noch irgendwie am PC an? Wenn die LED nicht mehr leuchtet kann es auch sein das der Brick im Bootloader ist. Was heißt denn du hast ein Labornetzteil als Spannungsquelle für die IO16 genommen? Was hast du genau gemacht?

Ich befürchte du wirst nicht drum rum kommen den Compiler von Sourcery zu installieren. Welche Abhängigkeit fehlt denn? Ich hab den Sourcery Compiler bei unter 64bit laufen.

Das Hardware Layout liegt dort auch (z.B. https://github.com/Tinkerforge/stepper-brick/tree/master/hardware). Da würden wir uns natürlich immer sehr über Verbesserungsvorschläge etc. freuen. Ein bisschen Geduld bis dort etwas umgesetzt wird ist allerdings notwendig, wir haben für die meisten Produkte jetzt eine ziemliche große Stückzahl an Leiterplatten machen lassen. Falls du Fehler auf einer spezifischen Platine meinst (etwas nicht richtig angelötet oder so) ist es vermutlich am besten an info@tinkerforge.com zu schreiben.

Wir nutzen das Issue-Tracking System von github: https://github.com/Tinkerforge

Ja, das hängt damit zusammen. Wir unterstützten im Moment keine 32Bit und keine PowerPC Macs. Du könntest versuchen brickv aus den Sourcen zu starten. Dafür musst du die entsprechenden Abhängigkeiten installieren (PyQt4, PyQwt5, pylab, scipy, pyopengl, numpy, matplotlib). Das ist zwar möglich aber leider ein bisschen Fummelei .

Das kann nicht so gelöst werden wie mit dem Arduino, USB kann die Timings die benötigt werden nicht einhalten. D.h. das komplette Kommunikationsprotokoll müsste übertragen werden, nicht die jeweils einzelnen Schritte. Das macht die Sache kompliziert.

In Theorie ist das sicherlich möglich. Die Frage ist natürlich wie man das Protokoll überträgt was per I2C gesprochen werden soll. Klingt nicht trivial.

Die Motivation war einfach eine konsistente API zu haben und nicht einen Teil per out-Parameter und einen Teil ohne out-Parameter zurück zu geben. Alternativ hätte man höchstens structs machen können, aber da C# out-Parameter als Feature bietet haben wir es halt genutzt. @Nic: Wir haben ja das Python Paradigma gerade nicht übertragen (da hätten wir dann structs nehmen müssen) sondern haben ein C# Paradigma genommen (out-Parameter).

@ThomasKI Der Stift an der Stiftleiste über den das PWM läuft liefert nicht genug Strom um eine LED zu steuern (Leistung bringt nur der Spannungs-Stift).

OK, dann scheint das I2C vom Master Brick nicht in Ordnung zu sein! Schreib mal eine Email an info@tinkerforge.com

Also du hast verschiedenste Bricklets, der Master ist auf der neuesten Version und keines der Bricklets funktioniert oder kann geflasht werden? Das ist ja komisch. Haben sie denn mal funktioniert? Und sie funktionieren jetzt nach dem Update des Masters nicht mehr? Edit: Was wird denn angezeigt wenn du die UID lädsts?

Ist das Bricklet auch an Port a angeschlossen?

Kannst du mal einmal probieren zuerst den Brick zu starten und dann das Bricklet anzustecken vor dem flashen? (damit das Plugin was auf dem Bricklet drauf ist nicht ausgeführt wird)

Das geht so direkt nicht. Du kannst aber ein callback_uid machen der aufgerufen wird von den unterschiedlichen callbacks. Also z.B. callback_uid(..., char *uid) { ... } callback1(...) { callback_uid(..., "uid1"); } callback2(...) { callback_uid(..., "uid2"); } ...

@insidERR: Die C# DLL sollte aus allen .NET Sprachen nutzbar sein!

Wir hatten uns vor Zeiten folgendes zu dem Thema ausgedacht: 1. Suchen einer Graph Library mit der man Objekte hin und herschieben kann, per Pfeile verbinden kann etc. 2. Brick Viewer erweitern um die Möglichkeit sehr einfache Abläufte darzustellen. 3. Abstrakte Knoten (neben den Bricks und Bricklets) hinzufügen die mathematische Berechnungen, Abzweigungen machen (Addition/Multiplikation, Skalierung, "Wenn x > y", etc.) 4. Kodierung des vom Benutzer erstellten endlichen Automaten (wir sind hier weit weg von Turing-Vollständigkeit!) in kompakte Form. 5. Ausführen des Automaten im Brick Viewer per Knopfdruck (einfach). 6. Jetzt kommt der Clou: Übertragung der Automatenkodierung auf den Brick und standalone ausführen auf dem Brick ohne PC-Verbindung (schwierig!). Das geht ein wenig in eine andere Richtung als das meiste hier vorgeschlagene. Einen Quellcodegenerator kann man sicherlich auch machen, das hat aber eine ganz andere Zielsetzung. Sobald wieder Quellcode generiert wird der dann vermutlich auch noch abgeändert werden muss um etwas komplexere Sachen zu machen, werden natürlich wieder nur Leute angesprochen die sich mit programmieren auseinandersetzen wollen (Installieren einer IDE, abändern von Code, kompilieren, etc). Falls wir selber sowas angehen würden, wäre die Zielsetzung das meine Mutter damit eine einfache Steuerung bauen kann. Ein Codegenerator ist natürlich auch cool, keine Frage .

The protocol we speak on USB is practically the same that we speak over TCP/IP. So i think we can do that in one go!

@AuronX Yes, you should be able to use the .dll of the C# Bindings in VB.net. But there is currently no documenation on how to do this and no sample code etc.

Wie gesagt, wenn eine Funktion etwas zurück gibt bekommst du ein Timeout (falls keine Antwort kommt). Wenn eine Funktion nichts zurück gibt (z.B. lcd_16x2_write_line) gibt es im Protokoll was wir auf der unteren Ebene Sprechen im Moment keine Möglichkeit einen Fehler zu bekommen.

Die Schaltung kannst du dir hier angucken: https://github.com/Tinkerforge/ambient-light-bricklet/raw/master/hardware/ambient-light-schematic.pdf ankommen solle maximal 3,3V beim AD Wandler! Der TEMT6000 zieht Strom abhängig vom der einfallenden Lichtstärke und je nachdem welche Widerstände wir wie beschalten resultiert das in unterschiedlichen Spannungen die vom AD Wandler gelesen werden können.

Klingt nach einer guten Idee, habs mir auf die TODO Liste geschrieben.

Bei Nachrichten die nichts zurück geben ist das schwierig, bei Nachrichten die etwas zurück geben bekommst du einen Timeout! Wenn du wissen möchtest ob ein Master noch ansprechbar ist könntest du also z.B. einmal get_voltage() aufrufen.