photron

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.

Die Frage ist warum qtbase5-dev nicht installiert wird. Versucht mal dies: sudo apt-get install qtbase5-dev Wenn apt-get da auch wieder so was sagt wie: qt5-default : Depends: qtbase5-dev but it is not going to be installed Dann versuch die Kette weiter abzusteigen und das Package zu installieren, was nicht installiert wird, bis du eine andere Meldung bekommst die dann hoffentlich aufschlussreicher ist.

Okay, habe das Problem gefunden. Es betrifft alle Bindings, nicht nur C/C++. Aber nicht in allen Bindings wird das Problem auch sichtbar. Das Problem ist, dass die Bindings erwarten, dass die Resistance als uint16 übertragen wird, das PTC Bricklet diese aber als int32 überträgt. Dadurch ist der Empfangsbuffer (response) in den C/C++ Bindings für diese Antwort 2 Byte zu kurz. Das verursacht die Stackcorruption die Visual Studio meldet. Das Problem wird mit der nächsten Version der Bindings behoben werden.

Ich kann das Problem nachstellen, wenn ich die Visual Studio IDE nehme. Wenn ich aber direkt den Visual Studio Compiler aufrufe tritt das Problem nicht auf. Es muss also mit den Compileroptionen zu tun haben. Muss ich mir genauer ansehen. So auf den ersten Blick ergibt das keinen Sinn.

Das Problem mit den zu großen Unterlegscheiben in aktuellen Mounting Kits ist bekannt, sorry. In älteren Mounting Kits waren die Unterlegscheiben kleiner. Wir sind dran und das Problem sollte in Kürze gelöst sein.

Der Monoflop arbeitet pro Pin, nicht pro Port. Du kannst für jeden der 16 Pins den Monoflop anders einstellen. Das set_port_monoflop() eine Bitmaske nimmt erlaubt es den Monoflop für mehrere Pins exakt gleich zu konfigurieren. Du kannst aber in der Bitmaske auch jeweils nur ein Bit gesetzt haben und dadurch jeden Pin anders einstellen. Bei get_port_monoflop() muss du den einzelnen Pin angeben, da die Antwort für alle 8 Pins eines Port zu groß für einen Nachricht wäre. Denn da jeder Pin anders eingestellt sein kann müsste 8x die Time (uint32) und 8x die Remaining-Time (uint32) und eine Bitmaske für das Value (uint8) zurückgegeben werden. Macht 65 Byte für eine 64 Byte Nachricht. Das klappt also nicht.

Das sieht nach einem Hardwareschaden aus. Auf der Unterseite des RED Brick sitzen unter dem USB-A Stecker zwei kleine schwarze Bauteile. Eins mit 4 Beinchen (siehe Bild) und eins mit 6 Beinchen. Ich erwarte, dass das mit 4 Beinchen fehle. Wenn das der Fall ist, dann melde dich bitte bei info@tinkerforge.com und verweise auf den Thread hier.