photron

Warum das Image bei dir nicht direkt funktioniert hat kann ich nicht sagen. Normalerweise ist der Ablauf: Image auf SD Karte schreiben, SD Karte in RED Brick stecken, RED Brick mit Strom versorgen, RED Brick bootet. Es kann sein, dass der erste Bootvorgang etwas länger dauert, weil das System dann noch Verschiedenes initialisieren muss, aber es sollte booten. Bezüglich DC Brick, der funktioniert direkt auf dem RED Brick, aber dazu muss er auf der aktuellen Firmware Versino sein: 2.3.0. Wenn auf dem DC Brick eine ältere Firmware ist, kann dass dein Problem erklären. Dies gilt für alle Bricks.

Es gab mal vor einer Weile einen ähnlichen Fall. Da war auch das Problem, dass die Bolzen ein klein bisschen zu kurz waren. Dadurch hat sich dann die Platine verbogen, wenn die Verschraubung fest angezogen wurde. Es ist durchaus möglich, dass das hier das gleiche Problem ist. Wenn dem so ist dann ist die Empfehlung die Verschraubung nur so fest anzuziehen, dass sich die Platinen nicht verbiegen. Nicht die schönste Lösung, ich weiß, leider kann ich dir derzeit keine bessere anbieten.

Richtig g_ether ist derzeit nicht verfügbar. g_ether wird aber in der kommenden Image Version 1.4 enthalten sein.

Im Log sehe ich, dass brickv mit brickd verbunden ist und einen Enumerate Request sendet, damit sich alle erreichbaren Bricks und Bricklets melden: <D> <client.c:278> Received request (U: 1, L: 8, F: 254, S: 2, R: 0) from client (N: 192.168.###.###:22030, T: plain-socket, H: 16, A: disabled) brickd sendet dann diesen Enumerate Request an einen Master Brick mit UID 6xCjQr über USB weiter: <D> <hardware.c:111> Broadcasting request (U: 1, L: 8, F: 254, S: 2, R: 0) to 1 stack(s) <D> <usb_transfer.c:262> Submitted write transfer 0x904af8 for 8 bytes to Master Brick [6xCjQr] <D> <stack.c:129> Forced to sent request to Master Brick [6xCjQr] Es kommt aber keine Antwort vom Master Brick. Das hab ich so noch nicht gesehen. Das muss aber kein Hardwarefehler sein. Es muss noch nicht mal sein, dass die Firmware neu aufgespielt werden muss. Es kann schon reichen den Brick einfach mal nur neuzustarten durch Reset Knopf drücken oder kurz die Stromversorgung trennen.

Erstmal vorweg: Flashen über das SAM-BA Tool mittels brickboot wird von uns nicht mehr supportet. Es kann durchaus sein, das brickboot nicht mehr kompiliert. Wie das Flashen mit dem SAM-BA Tool mal funktioniert hat kannst du in der alten Dokumentation nachsehen, die auf archive.org noch verfügbar ist. Du musst aber brickboot nicht selber kompilieren. Du kannst einfach die alten vorkompilieren brickboot Dateien für SAM-BA verwenden: http://download.tinkerforge.com/tools/samba/

Da wurde vor kurzem dran gearbeitet. Einige Änderungen waren noch nicht committet. Jetzt geht es wieder, danke für den Hinweis.

Du kannst mit einem WLAN USB Stick der den Access Point Modus unterstützt ein Raspberry Pi in einen Access Point verwandeln und dann dich vom iPhone aus direkt damit verbinden. Du brauchst aber das Raspberry Pi nicht zwingend als Proxy zwischen iPhone und Tinkerforge Bausteinen. Es geht auch ohne, wenn auch nicht so schön und einfach, mit dem Nachteil, dass du aus NetIO heraus dann das unser binäres Protokoll sprechen musst. Wenn du nur Steuerbefehle, wie das schalten eines Dual Relay Bricklets brauchst ist das nicht so schwer. Ich hab hier mal schnell ein einfaches Beispiel zusammen gebaut. Die NetIO Konfiguration ist angehängt plus modifizierte Shell Bindings, die das Binär Paket in hex ausgeben. Dieses muss dann bei den einzelnen Knöpfen unter "sends" eingetragen werden. Um diese hex Strings zu erzeugen muss du die modifizierten Shell Bindings wie folgt aufrufen. Dabei musst du statt fCp die UID deines Dual Relay Bricklets angeben. Relay 1 On: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 1 true Relay 1 Off: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 1 false Relay 2 On: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 2 true Relay 2 Off: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 2 false Dual_Relay_Test.json tinkerforge_netio

Firmware Version 2.2.* und 2.3.* sind inkompatible. Wenn ein Brick mit 2.3.* im Stack ist müssen alle anderen Bricks auch 2.3.* verwenden. Du musst also entweder den Master mit 2.2.1 upgraden auf 2.3.0, oder den Master mit 2.3.0 downgraden auf 2.2.*. Warum kannst du den einen Brick nicht updaten? Kannst du ihn nicht in den Bootloader Modus versetzen oder was ist da das Problem?

Dein Aufbau sollte so funktionieren, da ist erstmal kein grundsätzliches Problem. Wenn die rote LED am RED Brick nicht ausgeht dann bootet der Brick nicht, das ist richtig. Das kann verschiedene Ursachen haben. RED Brick mit Servo Brick bootet häufig nicht. Aber was ist mit RED Brick ohne Servo Brick, bootet der immer? Das Problem tritt also nur auf wenn der Servo Brick auf dem RED Brick steckt? Oder spielt das keine Rolle? Was ist mit dem Servo Brick, wenn du ihn vom RED Brick trennst und alleine per USB anschließt? Funktioniert der Servo Brick also grundsätzlich?

Das PWM Signal ist in dem Sinne erstmal komplett einstellbar. Was sind denn deine genauen Anforderungen an Frequenz sowie Duty Cycle Bereich und Auflösung? Dann kann ich dir da genauer antworten. Die Frage nach Servo Brick als PWM Generator kam schon mal im englischen Forum auf: http://www.tinkerunity.org/forum/index.php/topic,2227.0.html Daraus ist auch ein Beispiel hervorgegangenen: http://www.tinkerforge.com/de/doc/Software/Bricks/Servo_Brick_C.html#pwm-generator

Derzeit ist alle Tinkerforge Software nur mit IPv4 getestet. Es kann sein, dass es auch schon mit IPv6 funktioniert, das ist dann aber Zufall Über brickv kannst du derzeit einem RED Brick noch keine IPv6 Adresse zuweisen. Dass müsstet du wenn dann händisch im Linux auf dem RED Brick bewerkstelligen. Dass brickd schon IPv6 unterstützt ist ein erster Schritt, wann der Rest der Software folgt steht noch nicht fest. Daher ist das für brickd auch noch nicht dokumentiert. Du musst aber einfach nur in /etc/brickd.conf für die listen.address eine IPv6 Adresse wählen, z.b. :: (entspricht 0.0.0.0 in IPv4).

Ist korrigiert. Der source/ Ordner wird installiert, aber der example/ Ordner ist nicht dabei wenn du die Bindings über pip installierst. Hab eine Hinweis zur Dokumentation hinzugefügt. Stimmt, das fehlt im ersten Beispiel, im zweiten ist es drin. Hab's jetzt auch im ersten eingefügt.

Alle 2.x.y Brick/Bricklet Firmwares sind mit allen 2.x.y brickd Versionen kompatible. Da sollte dein Problem nicht liegen. listen.address = 0.0.0.0 bedeutet, dass brickd eingehende Verbindungen von überall her annimmt. Wenn du dort was anderes hinschreibst nimmt brickd nur noch Verbindungen von dort aus an. Das der Brick in lsusb auftaucht und auch brickd ihn grundsätzlich findet ist schonmal gut. Wenn der Master Brick in brickv nicht auftaucht dann antwortet er nicht auf Enumerate Requests. Wenn du dir das brickd.log (mit Log Level auf Debug) anschaust dann kannst du an folgenden Zeilen sehen wenn und ob der Brick antworten schickt: 2015-01-16 11:20:06.389351 <D> <packet|usb_transfer.c:122> Read transfer 0x1a1b830 returned successfully from Master Brick [6JLUGS] Und an folgenden Zeilen wenn brickd einem Brick erfolgreich eine Message geschickt hat: 2015-01-16 11:20:06.389685 <D> <packet|usb_transfer.c:122> Write transfer 0x1a1d730 returned successfully from Master Brick [6QjkqD] Hast du sollte Zeilen im Log?

Ich habe das mal kurz getestet, so sollte es gehen: Am einfachsten ist es wenn dein RED Brick ein Internetverbindung hat. Dann folgenden Schritte ausführen auf dem RED Brick: sudo vim /etc/apt/sources.list Oder mit irgendeinem anderen Editor /etc/apt/sources.list bearbeiten und folgende Zeile anhängen: deb [arch=armhf] http://ftp.debian.org/debian wheezy-backports main contrib non-free deb-src http://ftp.debian.org/debian wheezy-backports main contrib non-free Dann diese drei Befehle ausführen: sudo apt-get update sudo apt-get install qtchooser sudo apt-get install qt5-default Am Ende hast du dann Qt4 durch Qt5 ersetzt. Das wird dir dann auch brickv deinstallieren, da der Qt4 braucht. Das sollte aber kein Problem sein.

Ist das Problem bisher wieder aufgetaucht, oder hat die Master Brick Firmware ohne USB Hotplug Erkennung das Problem beseitigt?

Hört sich an als ob der RED Brick okay ist. Was passiert wenn du den Master Brick vom RED Brick und den Bricklet trennst und alleine an USB anschließt? Wenn er dann auch nicht auftaucht und keine LEDs leuchten, dann musst du ihn vielleicht neu Flashen: http://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-viewer

Yes.

Okay, das prepare-host.sh Script fügt jetzt automatisch i386 als Architektur hinzu. Die i386 Pakete sind für den armhf Cross-Compiler, darunter fällt auch das zlib1g Pakete. Das habe ich jetzt zur Liste der benötigen Pakete hinzugefügt. Node.js und NPM ist etwas problematisch. Das ist zu verschieden zwischen Ubuntu und Debian und den einzelnen Debian Versionen. Daher habe ich das jetzt aus der Liste der benötigen Pakete entfernt und in der readme.txt erklärt, dass man das bitte manuell installieren möge, plus Anleitung wie das für Ubuntu und Debian geht. Danke für das Finden dieser ganzen Probleme. Wenn du noch mehr findest immer nur her damit

raphael_vogel, auch eine gute Idee, hat aber den gleichen Nachteil wie die Shell Bindings als Proxy: es braucht einen weiteren PC für den Webserver. doehlma, beschreibe doch mal bitte genauer was deine Rahmenbedingungen sind: Soll es mit iPhone und Stack alleine gehen, oder darf die Kommunikation über einen zusätzlichen PC gehen? Du sagtest du hast schon Verschiedenes probiert. Beschreibe doch mal was das im einzelnen war und was die Probleme waren, dann können wir hier gezielter weiterhelfen.

Maybe the Master Brick itself get's restarted if you reboot the Linux, which doesn't happen if you just restart brickd. You could test to manually reset the Master Brick with its reset button if the problem occurs again to check this. Does the problem occur when you switch the Dual Relay Bricklet?

Das ist keine Variante, denn das ist der Standard und die einzige Möglichkeit. Auf dem RED Brick läuft immer ein eigener brickd. Es ist in diesem Zusammenhang mit dem RED Brick genau das gleiche wie mit dem Master Brick. Wenn du eine Brick per USB anschließt, dann muss auf dem PC an dem der Brick per USB angeschlossen ist brickd laufen. Denn brickd ist für die Übersetzung von USB nach TCP/IP zuständig. Die API Bindings und brickv nutzen immer TCP/IP. Wenn du aber einen RED ober Master Brick nicht per USB anschließt, sondern ihnen z.B. der Ethernet Extension direkt Netzwerkzugang gibts, dann brauchst du keinen brickd auf dem PC mehr. Denn dann können die API Bindings und brickv direkt mit dem Brick über TCP/IP sprechen, ohne den Umweg über USB. Um auf deine Frage zurückzukommen: Da müssen wir nicht mehr für tun, denn genau das kannst du schon lägst tun

Brick und Bricklets sprechen auf der untersten Ebene ein binäres packetbasiertes Protokoll, das hier beschrieben ist: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Unsere API Bindings nutzen diese Protokoll um mit den Brick und Bricklets zu sprechen. NetIO ist an sich erstmal für Textbefehle ausgelegt. Die Shell Bindings können als Proxy zwischen NetIO und Brick und Bricklets fungieren, so dass du direkt Textbefehle von NetIO aus schicken kannst: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html Das setzt allerdings voraus, das die Shell Bindings auf einem Rechner laufen. Wenn du direkt aus NetIO über eine WIFI Extension Brick und Bricklets ansprechen willst ist da kein Raum für die Shell Bindings. In diesem Fall kannst du das Format der NetIO Connection von string auf hex zu stellen und dann direkt die Binärpakete zu schicken. Als kurzes Beispiel müsstet du diese Bytesequenz senden, um beide Relais des Dual Relay Bricklets mit UID a5N einzuschalten: 0x5a 0x77 0x00 0x00 0x0a 0x01 0xb0 0x00 0x01 0x01 Wie diese für dein Bricklet aussieht hängt von dessen UID ab. Wie du das in NetIO exakt hinschreiben musst musst du in der NetIO Dokumentation nachschlagen.

Mit getListLength() und getListItem() kannst du die Einträge der Programmliste abfragen, dir durch programs_list_id repräsentiert wird. Mit den program_ids aus der Liste kannst du dann wiederum startProgram() aufrufen. Um in der Programmliste das Programm zu finden, dass du suchst kannst du mit getProgramIdentifier() von einem Program dessen Identifier abfragen. Über getProgramIdentifier() erhälst du die identifier_string_id mit der du dann über getStringLength() und getStringChunk() den Inhalt des Strings abfragen kannst.

Die LEDs am RED Brick und am Master Brick leuchten aber normal, oder? Also am RED Brick blinkt grün, blau leuchtet und rot ist aus (unter der Annahme du hast das nicht umgestellt). Am Master Brick leuchtet die eine blaue LED und die 4 am Rand machen das übliche Muster beim Anstecken an USB.

npm ist der Node.js Package Manager, denn scheint es wohl nur bei Ubuntu direkt als Package zu geben. Das müssen wir wohl behandeln. Bis dahin gibt es hier für Debian eine Anleitung: https://github.com/joyent/node/wiki/installing-node.js-via-package-manager libstdc++6 ist nicht libc6, sondern die C++ Standard Library. Villeicht ist das Problem, dass die für i386 installiert werden soll. Was gibt das hier bei dir aus? dpkg --print-foreign-architectures Wenn da i386 nicht bei ist kannst du es so hinzufügen: dpkg --add-architecture i386 Dann sollte es gehen.