photron

Ich würde erstmal testen, ob du das ohne libudev ans laufen bekommst und wenn das funktioniert mir dann erst über libudev Sorgen machen.

Okay, die Konfiguration sieht so erstmal okay aus. Klick mal bitte im Brick Viewer auf dem WIFI Tab unten rechts auf den "Show Status" Knopf und zeig auch mal Screenshot davon. Dort siehst du ob die WIFI Extension verbunden ist und welche IP Adresse sie bekommen hat. Was für einen WLAN Router verwendest du?

Ja, wenn du von Source installiert dann installiert das die .so und .h Dateien. Das installiert dann das was die libusb-1.0 und libusb-1.0-dev Packages installieren würden.

The way the LEDs light up initially is correct. That the LEDs don't light up at all now probably means that the Brick is in boot loader mode. This could happen if you accidentally hold the erase button on the Brick while connecting it to USB. You can try to flash the firmware to the Brick again, see: http://www.tinkerforge.com/en/doc/Software/Brickv.html#using-brick-viewer If the Brick doesn't show up as serial port during the flash process then please check if your Master Brick is missing the small black 4-pin part on the bottom side that is marked in the attached picture. If that's the case then the USB data lines are interrupted and USB communication doesn't work. Please contact us at info@tinkerforge.com with your order number and mention this forum thread.

Du kannst libusb aus Source installieren, dass sollte prinzipiell funktionieren mit folgenden Befehlen: wget https://github.com/libusb/libusb/releases/download/v1.0.21/libusb-1.0.21.tar.bz2 tar xf libusb-1.0.21.tar.bz2 cd libusb-1.0.21 ./configure make sudo make install Am besten deinstalliert du dann vorher das libusb Package, damit die sich nicht in die quere kommen. configure wird sich aber wahrscheinlich über das Fehlen von libudev beschweren. Du muss dann also entweder libudev + Header installieren oder libusb ohne libudev und damit auch ohne Hotplug Support verwenden. ./configure --disable-udev

Kannst du bitte in beiden Fällen den Stapel per USB mit dem PC Verbinden und jeweils einen Screenshot vom WIFI Status Fenster in Brick Viewer machen und hier zeigen? Ich vermute, dass im Client Modus was mit der IP Adresse der WIFI Extension nicht passt und du sie deshalb nicht erreichen kannst.

Ich denke du hast das richtig verstanden. In Client Modus verbindet sich die WIFI Extension mit einem bestehenden WLAN und holt sich von dort per DHCP eine IP Adresse ab, genau so wie dass dein Laptop oder Smartphone auch tut. Darüber solltest du dann auch unter der IP Adresse, die die WIFI Extension per DHCP erhalten hat, die Webseite der WIFI Extension erreichen können. Im Access Point Modus stellt die WIFI Extension selbst einen Access Point auf den du dich verbinden kannst und per DHCP eine IP Adresse beziehen kannst. Kannst du für beide Fälle (Client Modus Only und Access Point + Client Modus) das WIFI Status Fenster aus Brick Viewer, oder die Status Ansicht der WIFI Extension Webseite zeigen?

Das Makefile verwendet pkg-config um libusb zu finden. Das ldconfig die .so Datei auslistet ist nicht genug. Das sagt nichts darüber aus, ob die libusb Header installiert sind und ohne die Header funktioniert das Kompilieren nicht. libusb-1.0 ist schon das richtige Package, aber du brauchst das Development Package dazu (unter Debian: libusb-1.0-0-dev), um brickd von Source kompilieren zu können. Teste mal was diese beiden Befehle ausgeben: pkg-config --modversion libusb-1.0 pkg-config --list-all | grep libusb Aber ich würde erwarten, dass du einfach nur die .so Datei hast und der Rest fehlt. Ich würde sogar fast erwarten, dass da nicht mal ein Compiler drauf ist. Was gibt folgender Befehl aus? gcc --version Diese Router OSe sind nicht dafür gemacht auf dem Router selbst Software zu kompilieren. Normalerweise hat man da ein Build System auf dem PC mit dem man ein angepasstes Router Image bauen kann. Dort musst du dann brickd integrieren, denke ich.

Du hast UID und Position durcheinander gebracht. Dein LCD Bricklet ist an Bricklet Port B am Master Brick angeschlossen. Du musst aber dessen UID angeben, nicht den Port. Die richtige UID kannst du in Brick Viewer ablesen und ist typischer Weise für Bricklets 3 Zeichen lang, zum Beispiel: z5U.

Auf den ersten Blick sieht das aus als wäre das eine Warnung darüber das ein Socket Send Buffer fast voll wäre. Sendest du viele Daten? Wieviel RAM hat der RED Brick noch frei? Sprich was gibt der free Befehl auf dem RED Brick aus?

An RS485 Extension is already exposed as /dev/ttyS0, but you cannot use it because brickd is using it. So you either need to disable brickd on the RED Brick or patch brickd to be able to use an RS485 Extension as a normal serial port on the RED Brick.

Okay, vergiss das Log und gdb. Ich kann das Problem selbst erzeugen. Teste mal bitte die angehängt Version. brickd_macos_2_2_3_74cf8c7.dmg

Kannst du mir dazu das /var/log/brickd.log schicken? Wobei das wahrscheinlich nicht hilfreich sein wird. Kannst du mit gdb umgehen und ein Backlog des Crashes erzeugen?

Okay, dann hast du ein anderes Problem. Hilft es, wenn du die Bricklets absteckst, oder die Abstandsbolzen abschraubst? Das sollte normalerweise kein Problem sein, das ist eher ein Schuss ins Blaue. Kannst du auch ein Foto der Oberseite machen?

Schau mal bitte, ob auf der Unterseite das im Bild markierte Bauteil mit 4 Beinchen noch da ist. Wenn nein, dann erklärt das dein Problem, denn dann sind die USB Datenleitungen unterbrochen. Wenn du uns den Master Brick einschickst können wir das reparieren.

Brick Daemon 2.2.3 Update bundled libusb to 1.0.20 on Windows, add support for Intel Alpine Ridge USB 3.1 controller Update bundled libusb to 1.0.20 on Mac OS X Merge --debug and --libusb-debug options Properly quote path to brickd.exe for service registration on Windows Switch to .pkg based installer for Mac OS X Fix crash in RS485 Extension code for RED Brick Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.2.3 libusb für Windows auf Version 1.0.20 aktualisiert, fügt Support für Intel Alpine Ridge USB 3.1 Controller hinzu libusb für Mac OS X auf Version 1.0.20 aktualisiert Kommandozeilenoptionen --debug und --libusb-debug zusammengefasst Pfad mit Leerzeichen zur brickd.exe für Service Registration auf Windows wird jetzt korrekt behandelt Für Mac OS X wird jetzt .pkg basierter Installer verwendet Crash im RS485 Extension Code auf dem RED Brick behoben Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

The RED Brick runs a slightly modified Debian Linux. But there is nothing in place that would undo modifications to the Linux System. Therefore, you modifications should not be lost on reboot. Can you explain in more detail what you did/changed?

Gibt debug() den $packet als ASCII oder UTF-8 aus? Das erklärt vielleicht deine "2", denn $packet enthält Binärdaten die nicht ASCII und auch nicht UTF-8 sind. Gib mal bitte bin2hex($packet) statt direkt $packet aus. Test auch bitte auf "strlen($packet) < 8" statt < 4.

Dann schau mal bitte auf der Oberseite der IMU hinter dem USB Stecker. Da sitzen zwei kleine schwarze Bauteile. Wenn das mit den vier Beinchen fehlt, dann erklärt das dein Problem, weil dann die USB Datenleitungen unterbrochen sind. Möglicherweise ist das beim Ersten in den Bootloader bringen abhanden kommen. Es gab da bei einer Charge IMUs Lötprobleme mit diesem Bauteil. Es scheint als wäre da ein nicht gut angelötetes Exemplar durch unsere Tests gerutscht, sorry. Wir reparieren das, wenn du uns die IMU zuschickst.

Dann bleibt eigentlich nur noch ein irgendwie gearteter Hardwaredefekt. Lassen sich beide Taster an der IMU normal drücken? Sprich, machen beiden beim Drücken ein Klickgeräusch und stecken nicht fest? Zum beschriebenen Verhalten würde es passen, wenn der Reset Taster klemmen würde und so die IMU dauerhaft im Reset Zustand hält.

reinweb, du hast keine Datei an deinen Post angehängt. Kannst du was über den zeitlichen Zusammenhang dieser 3 Zeilen sagen? Alle 3 Zeilen hängen mit dem Entpacken des Packet Headers zusammen. Alle drei sehen so aus als ob sie einen zu kurzen Header behandeln. Die receive Funktion ruft aber die handleResponse Funktion nur auf, wenn die komplettes Packet mit vollständigem Header empfangen wurde. Die einzige Möglichkeit die ich im Moment für diese Fehler sehe, ist, dass ein kaputtes Packet empfangen wurde in dem das Längen Feld im Header einen ungültigen Wert (kleiner 8 Bytes) enthalten hat. Das wird momentan noch nicht geprüft, steht aber auf der Todo Liste, dass in allen Bindings zu verbessern. Die Frage ist jetzt wo dies kaputtes Packet hergekommen ist. Interessant wäre es den Inhalt der $packet Variable zu sehen, wenn diese Fehler auftreten.

Bindings: JavaScript 2.0.11 Use browserify 13.1.1 to avoid the code hanging in Firefox Fix handling of fragmented packets Download: JavaScript

Bindings: JavaScript 2.0.11 Generator nutzt mindestens browserify 13.1.1 um Codehänger in Firefox zu vermeiden Behandlung fragmentierter Packets korrigiert Download: JavaScript

Es kommt in seltenen Fällen vor, dass ein Brick in einem komischen Zwischenzustand gerät. Dann hilft es aber normalerweise den Brick nochmal in den Bootloader Modus zu versetzen. Alternativ, statt den Erase Taster gedrückt halten und dabei einmal kurz Reset zu drücken, kannst du auch den Erase Taster gedrückt halten und dabei das USB Kabel einstecken, um den Brick in den Bootloader zu bekommen. Der Punkt ist, dass der Erase Taster gedrückt sein muss, wenn der Mikrocontroller des Brick startet, entweder durch Reset Taster drücken oder USB/Strom anstecken. Wenn du den Brick so in den Bootloader bekommen hast musst du allerdings nach dem Flashen den Brick von Hand neustarten.