borg

Das ist schwierig umzusetzen. Per USB kann ich mit maximal 1000 Nachrichten pro Sekunde rechnen und das System ist entsprechend darauf aufgebaut. Zum Beispiel ruft unser interner Scheduler pro Bricklet Plugin nur 1x pro ms eine Task auf, wir können also auch nur 1x pro ms eine Zustandsänderung haben. Auf den meisten Bricks sind für sowas auch keine PWM oder Timer Counter Hardware Einheiten mehr über. Du musst bedenken das so ein Master Brick ja auch noch mit x Stack Teilnehmern und x Extension Slave Teilnehmern gleichzeitig sprechen können muss. Und die Treiber Bricks (Servo/Stepper/DC). Müssen ihre jeweilige Motoren steuern und Beschleunigungen/Debeschleunigungen etc. Berechnen. Das tut brickd bereits.

Neue Bindings würde ich jetzt auch einfach mal als neues "Produkt" bezeichnen. Hab das oben mal entsprechend geändert. Viel mehr Aufwand machen mehr Bricks/Bricklets allerdings nicht beim erstellen neuer Bindings, die werden ja soweit autogeneriert. Der Mehraufwand ist dann nur in den Beispielen, die kann man natürlich schlecht generieren.

Der Name "GrauTec" stammt aus der usb.ids Datei vom Linux Kernel: http://www.linux-usb.org/usb.ids Das können wir so von außen erstmal nicht beeinflussen. Ich schreibe Stephen J. Gowdy diesbezüglich mal an, aber ich kann nichts versprechen.

Die Prototypen werden von uns von Hand ausgeschnitten, von Hand mit Lötpaste versehen, in unserem kleinen Prototypen-Ofen gebacken und dann nachbearbeitet um Brücken zu entfernen. Der Prozess ist _viel_ zu Aufwendig um damit eine verkaufbare Stückzahl Prototypen herzustellen. Und eine kleine Anzahl Prototypen vom Bestücker fertig machen zu lassen wäre absurd teuer und auch sehr ärgerlich wenn dann noch ein Fehler auf der Schaltung ist.

Das ist allerdings eine gute Idee, ich hab die maximalen Stimmen mal auf 3 gestellt. Aber ich befürchte wer schon abgestimmt hat darf nicht nochmal abstimmen .

Die ist definitiv schon längst überfällig, leider kommt immer wieder etwas anderes dazwischen. Die Software ist soweit fertig, es fehlt noch ein bisschen testen und ein bisschen Bugfixing. Es ist leider im Moment so das nach 30-120 Minuten laufen die Verbindung abbricht und ich konnte noch nicht herausfinden warum. Solche Fehler sind natürlich auch immer schwer ausfindig zu machen.

VID_03EB und PID_6124 bedeutet er ist im Bootloader. Einmal ganz von vorne. Installiere sam-ba und entpacke die sam-ba files in den sam-ba ordner. Dann stecke den Brick an während du den Reset Taster drückst (damit stellen wir sich das er auch wirklich im Bootloader ist). Dann wählst du folgenden Treiber aus: SAM-BA-ORDNER\drv (nicht den Treiber der in brickd\drivers liegt!). Falls er nicht nach einem Treiber fragt einmal über die Treiber aktualisieren die Treiber per Hand auswählen. Dann sam-ba starten und die Prozedur so durchführen wie in der Doku beschrieben. Wenn der Brick sich wieder als Brick anmeldet, dann den Treiber in Tinkerforge\Brickd\drivers auswählen (wenn du das schon einmal getan hast macht er das automatisch)!

So, hier mal eine Liste von möglichen neuen Produkten. Ich bin einmal diesen Thread durchgegangen: http://www.tinkerunity.org/forum/index.php/topic,24.0.html und hab noch alles dazu aufgeschrieben was von uns geplant ist. Die ersten 5 davon stehen schon ziemlich fest. Interessant für uns ist natürlich in welcher Reihenfolge wir diese nun machen sollen. Wir haben vor auf dauer alle 2 Wochen ein neues Feature/Produkt zu veröffentlichen (neues Brick/Bricklet, neue Extension, neue Bindings, On Device Programming Interface etc). Wobei wir bei Bricklets mit ca. 3 Monaten rechnen bis etwas vom Prototypen-Status in die Produktion gehen kann (1,5 Monate bis zum funktionierenden Prototyp und 1,5 Monate bis zur Produktion). D.h. wenn jetzt eine gute neue Idee kommt dauert es mindestens 3 Monate bis sie erwerblich ist. Um zu zeigen das nicht alles Vaporware ist bei uns, hier die bisherigen Prototypen die wir hier haben : http://i.imgur.com/xmSaQ.jpg V.l.n.r.: GPS Bricklet, Barometer/Altimeter Bricklet, Sonic Range Bricklet, neues Current Bricklet, Incremental Encoder Bricklet

In das SAM-BA Verzeichnis müssen nicht die neuen Firmwares rein sondern die "SAM-BA Files": http://download.tinkerforge.com/tools/samba/samba_files_1_0_0.zip Dort drin ist ein Bootloader für die Bricks. Die Bricks haben einen unlöschbaren minimalen Bootloader drauf der lädt diesen Bootloader um dann die neue Firmware zu flashen . Also einfach die Dateien im SAM-BA Ordner entpacken und dann sollte eine passende Auswahl da sein.

Auch eine Master Extension. Ja, ja und ja .

Wir benutzen den KS0066U LCD Controller mit dem Standard English/Japanese Zeichensatz. Hier gibt es eine Tabelle mit dem Zeichensatz: http://www.display-elektronik.de/CHAR_KS0066-00(Engl-Japan).PDF 0b11011111 sieht aus wie ein °. Also in Python z.B. lcd.write_line(0, 0, chr(0b11011111)) (habs gerade getestet, es funktioniert so)

Der Prototyp mit dem wir im Moment arbeiten basiert auf diesem Modul hier: http://www.rovingnetworks.com/products/RN_171 Also leider nur 2.4GHz.

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 .