borg

Du benötigst einen Compiler der cortex-m3 vernünftig unterstützt, das tut der aus den Debian/Ubuntu repos z.B. definitiv nicht. Mit crosstool sollte das schon eher gehen, ich habs aber noch nicht getestet. Google spuckt mir das hier raus: http://www.curtisembedded.com/wiki/bin/view/CortexM3/SettingUpDevelopmentSystem Da baut jemand einen cortex-m3 compiler mit crosstool und nutzt auch FreeRTOS (nutzen wir auch).

Bei WLAN gibt es einen Stack mit einer WLAN Extension oben drauf. Den kannst du direkt ansprechen (beim connect die IP der WLAN Extension angeben anstatt localhost). Da gibt es kein Master/Slave! Der Slave ist dein WLAN Router wenn du so willst, oder bei einem Ad Hoc Netzwerk dein PC/Tablet/Handy.

A little bit late, but the TCP/IP protocol documentation is now ready: http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#tcp-ip-ip-connection

TCP/IP Protokoll Dokumentation ist jetzt fertig! http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#tcp-ip-ip-connection

Über patches sind wir natürlich immer Dankbar, ich hab gerade erst noch ein merge request betreffend der C# Bindings bei github gepulled: https://github.com/Tinkerforge/generators/pull/3 Falls die Änderung etwas an der nach außen sichtbaren API ändert ist die Hürde das ich so ein patch annehme natürlich größer, da muss es sich dann schon wirklich lohnen (Es muss dann ja schließlich jeder Kunde seinen Code ändern wenn er updated)!

Chibi hat (zumindest in Theorie) eine erheblich höhere Reichweite als WLAN. Eine einzelne Chibi Extension ist auch erheblich günstiger als die WLAN Extension sein wird. Bei allem anderen sollte die WLAN Extension im vorteil sein. Ein gleichzeitiger Betrieb ist kein Problem, die Frequenzen sind total unterschiedlich. Falls du vor hast das Chibi Netzwerk noch zu vergrößern solltest du jetzt zuschlagen, wir werden vermutlich keine neuen Chibi Extensions mehr machen wenn die jetzige Produktion verkauft ist. Dies hat zwei Gründe: * Wir erwarten das die WLAN Extension erheblich mehr gefragt sein wird (direktes steuern vom Handy etc). * Bei einigen Kunden macht die Chibi Extension Probleme die wir hier absolut nicht nachvollziehen können (schlechte Verbindung, Störung durch Funkthermostate, etc). Solche Probleme wird es bei WLAN nicht geben. Falls es auch in Zukunft eine riesige Nachfrage nach der Chibi Extension geben sollte können wir sie natürlich nochmal auflegen .

Wir haben uns kurz angeguckt was da passiert, wenn du glück hast ist nur eine Diode und/oder die Stromversorgung kaputt. Der Prozessor sollte keinen Schaden genommen haben. Meld dich mal bei info@tinkerforge.com mit der Bestellnummer, wir gucken dann mal was wir machen können.

Sehr komisch. Die Packages kommen alle aus dem Ubuntu Repo, das sieht gut aus. Ich benutze hier im Moment noch 10.11, da gibt es solche Probleme definitiv nicht. Google hat mir diesen Foreneintrag rausgeschmissen, eine Lösung gibt es da aber leider auch nicht: http://ubuntuforums.org/showthread.php?t=1880965

Ich benutze kein chroot. Du kannst nicht ia32-libs installieren? Hast du irgendwelche Fremdquellen in der sources.list? Irgendwas, was eine ältere Version der ia32-libs installiert? Was sagt apt-cache policy ia32-libs apt-cache policy ia32-libs-multiarch apt-cache policy libcurl3:i386 ?

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)