photron

Brick Daemon 2.2.1 RED Brick Hotplug Erkennung und Fehlerbehandlung auf Windows verbessert Debug-Filter zur Feineinstellung der Debug-Ausgabe hinzugefügt Auf WebSocket Handshake warten bevor Daten gesendet werden redapid Version wird als RED Brick Firmware Version verwendet Packet wird nach Partial Write nicht mehr fälschlicherweise noch ein zweites Mal gesendet Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Es ist sicherlich schon ein Unterschied ob du zwischen zwei Rechnern übers Netzwerk kommunizierst oder nur auf einem mit sich selbst über die Loopback Schnittstelle. Da würde ich die Flinte nicht gleich ins Korn werfen. Wie ist den dein bisheriger Aufbau genau?

Der Power Knopf am RED Brick bezieht sich nur auf den RED Brick. Der Rest des Stacks hat damit nichts zu tun. Die Stromversorgung des Stacks ist vom Stack aus intern nicht schaltbar. Wenn dann muss diese extern getrennt werden.

Mit dem RED Brick entfällt die USB Verbindung, wenn du das Bricklet an einem Brick angeschlossen hast, dass auf den RED Brick gesteckt ist. Die Netzwerkverbindung bleibt, wenn auch in anderer Form. Dein Programm auf dem RED Brick verbindet sich immer noch über localhost mit dem brickd auf dem RED Brick. Potentiell könnte das mit Auswertung auf dem RED Brick schneller/stabiler werden, weil du die externe Netzwerkverbindung nicht mehr in der Kommunikationskette hast. Das hängt aber wirklich davon ab wo dir in deinem jetzigen Aufbau die 10-20ms verloren gehen.

Welche Linux Distribution verwendest du? Serielle Schnittstellen sind normalerweise der Gruppe dialout zugeordnet und normalerweise ist der Standardnutzer auch in dieser Gruppe. In diesem Fall funktioniert alles wie beschrieben. Wenn der Nutzer nicht in der dialout Gruppe ist kann man das Problem mit sudo umgehen. Alternative kann der Nutzer auch der dialout Gruppe hinzugefügt werden. Ich habe die Fehlermeldung in brickv jetzt um den Hinweis erweitert brickv als root zu starten und den entsprechenden Hinweis auch in die Dokumentation aufgenommen. Wo hast du gelesen, dass du den USB Stecker einstecken sollst während du Erase gedrückt hältst? Was eigentlich passieren muss ist, dass Erase gedrückt ist wenn der Brick startet. Das kannst du auf zwei Wegen erreichen: - Entweder wie dokumentiert: Brick an USB anschließen, Erase gedrückt halten und dabei Reset drücken. Das Ziel ist, dass beim Loslassen von Reset der Erase Knopf gedrückt ist. - Die andere (undokumentierte) Weise: Erase gedrückt halten und dabei USB anstecken. Der Brick startet dann beim Anstecken von USB, kein Reset Knopf nötig. Beides führt zum Ziel. Wir haben aber absichtlich nur eine Weise dokumentiert, um Verwirrung zu vermeiden. Hat scheinbar nicht geklappt Ich habe die Beschreibung in der Dokumentation jetzt hoffentlich verständlicher umformuliert.

Ich sehe gerade dein spezielles Problem mit tinkerforge_touch_calibrator.py solte im aktuellen git Stand behoben sein. Ich rate dennoch dazu den Stand vorm Wechsel zu jessie zu verwenden, da gerade noch sehr vieles nicht mehr funktioniert und erst für jessie korrigiert werden muss.

Wir arbeiten gerade am nächsten Release des Image und sind gerade noch mitten drin. Es kann sein, dass der aktuelle git Stand nicht funktioniert, sorry. Du kannst versuchen auf den git Stand vor dem Wechsel zu Debian jessie zurück zu gehen, der sollte funktionieren. Das ist dieser commit: https://github.com/Tinkerforge/red-brick/commit/543cf3fb5a997cdb3f6c00b24ae590480d3807ef

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