borg

Das ist leider Protokollbedingt gar nicht so einfach umzusetzen. Wenn du ein Enumerate erzwingst wird eine broadcast Nachricht losgeschickt auf die alle Bricks/Bricklets antworten. D.h. der Master bekommt die Enumerate Nachricht, Antwortet darauf (mit seinem Namen, Version etc) und gibt die Nachricht dann weiter an alle seine Bricklets, Stack Teilnehmer und Extension Slaves. Die geben es entsprechend auch wieder weiter an alle Bricks/Brickelts die sie kennen. Das funktioniert so weit ganz gut und es ist auch garantiert das jedes Brick/Bricklet erreicht wird, allerdings weiß kein Teilnehmer des Systems wann die letzte Nachricht rausgeht! Der einzige der überhaupt weiß wieviele Teilnehmer es im System gibt ist brickd. Im hinblick auf die WLAN Extension füge ich dem allerdings nur ungerne mehr Intelligenz hinzu, weil das die Implementierung für die WLAN Extension später viel aufwendiger machen würde.

When the RS485 Extension is available you could write your own firmware (low-level C) that controls DMX devices. I don't know anything about the DMX protocol, but this would probably be quite a big task!

Oh, das ist aber ein Bug in den Bindings. Wir müssen Strings an der Stelle in Python 3 einfach anders behandeln.

OK, hab mal den =&r Fix committet.

Oh, mir war gar nicht aufgefallen dass das hier der gleiche Fehler ist wie der schon im englischen Forum aufgetreten war. Nach kurzem durchwühlen der GCC ARM inline Assembler Dokumentation bin ich mir nicht sicher ob der Fix von AreaScout funktioniert. Ich hab aber folgendes gefunden; Kann einer von euch ausprobieren ob der kram mit "=r" (result) funktioniert? Falls ja würde ich das einbauen, weil kaputt machen kann das an der Stelle definitiv nichts, höchstens langsamer.

Ich bekomme den Fehler nicht, welche Compiler Version verwendet ihr denn?

Ich würde behaupten bis auf DC/Stepper/Servo Bricks kannst du alles in ein geschlossenes Gehäuse packen ohne das es zu heiß wird. Bei der CPU ist der Stromverbrauch extrem abhängig davon welche Hardwareeinheiten aktiviert sind, die Werte die wir angeben sind Durchschnittswerte.

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.