photron

Brick Daemon 2.0.5 Nicht-portable Verwendung von Bitfelder korrigiert Big Endian Byte Order wird nun korrekt behandelt UIDs werden im Log in Base58 angezeigt Debian i386 Package wird jetzt wirklich für i386 compiliert, anstatt i686 Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Loetkolben, in beiden lsusb ausgaben ist 16d0:063d als VID:PID drin. Das ist der Brick normal gestartet, er ist nicht im Bootloader.

/dev/bus/usb/002/002 ist das USB Device an sich. Das ist hier nicht richtig. Du brauchst da den seriellen Port den der Bootloader des Bricks über USB anbietet. Typischerweise taucht der als /dev/ttyACM0 oder /dev/ttyUSB0 auf.

Richtig, exakt so läuft das. Denn nur so ist das kompatible zu älteren Firmwares. Die beiden genannten Dinge sind jetzt dokumentiert.

Das wurde vergessen zu dokumentieren, sorry. Die TCP/IP Dokumentation ist jetzt wieder aktuell.

In /usr/local/lib/python2.6/dist-packages/easy-install.pth sollte sowas wie import sys; sys.__plen = len(sys.path) ./tinkerforge.egg import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new) stehen und easy_install -m tinkerforge sollte daraus die ./tinkerforge.egg Zeile entfernen.

Hier ein .deb für i386 das jetzt auch wirklich mit gcc -march=i386 gebaut wurde. Wenn ich das Problem richtig verstehe sollte das jetzt bei dir funktionieren. brickd-2.0.4_really_i386.deb

easy_install hat kein wirkliches Uninstall Kommando. Man kann ein mit easy_install installiertes egg aber wie folgt wieder sauber entfernen: sudo easy_install -m tinkerforge Dies trägt tinkerforge aus der Modulliste wieder aus. Dieser Befehlt gibt die dann auch was wo das entpackte egg liegt: $ sudo easy_install -m tinkerforge Searching for tinkerforge Best match: tinkerforge 2.0.5 Processing tinkerforge.egg Removing tinkerforge 2.0.5 from easy-install.pth file Using /usr/local/lib/python2.7/dist-packages/tinkerforge.egg Dann noch dass entpackte egg manuell entfernen: sudo rm -rf /usr/local/lib/python2.7/dist-packages/tinkerforge.egg

Das erste was mir gerade auffällt ist das brickd-*_i386.deb auf einem i686 Rechner compiliert wird und daher eigentlich i686 ist. Kann es sein, dass du einen CPU < i686 hast? Was gibt "uname -a" aus? Was gibt "gcc -Q -v" aus, falls du gcc installiert hast?

Was du da im WIFI Fall siehst sind Enumerate Callbacks mit ENUMERATION_TYPE_CONNECTED. Diese sendet der Stack von sich aus wenn eine neu Verbindung aufgebaut wurde. Dies erlaubt es neustartende Stacks zu erkennen. Im Fall von USB siehst du diese nicht, da die USB Verbindung zwischen brickd und Stack schon längst besteht und auch durchgehend besteht. Bei WIFI stellst du direkt die Verbindung her und siehst daher die Enumerate Callbacks. Soll heißen, du kannst dich nicht darauf verlassen, dass die Daten die nach Absenden eines Request auch direkt die Antwort darauf sind. Auch kann es sein, dass du mehrere unserer Pakete in einem TCP/IP Paket bekommst. "Shell Bindings" stehen schon eine Weile auf der TODO Liste.

Beides durchaus sinnvolle Vorschläge. Die nächsten Bindings werden höchstwahrscheinlich für LabVIEW sein.

Ist korrigiert, danke für den Hinweis.

Das nenn' ich mal einen stabilen und wetterfesten Aufbau

Hab's gerade eingebaut. Qt bietet da gleich eine Option für. Ist dann in der nächsten brickv Version mit drin.

Argh, irgendwie ist in dem Stück Dokumentation der Wurm drin. Sorry. Es muss natürlich "device_identifier - uint16" lauten und ist jetzt auch korrigiert. Danke für die Hinweise.

Nein, das ist richtig. Auf TCP/IP Ebene sind uid und connected_uid des Enumerate Callbacks uint32, genauso wie die UID im Header jedes Packets auch uint32 ist. Die Bindings machen dann die Umwandlung zwischen Base58 und uint32, damit die UIDs auf Benutzerebene immer Base58 sind. Edit: Du hast recht, die Dokumentation passte nicht. Ich habe mich da an eine erste Version von Protokoll 2.0 erinnert, sorry. Dokumentation ist jetzt korrigiert.

Wenn der IPConnection.Connect() Aufruf keine Exception wirft, dann konnte eine TCP/IP Verbindung aufgebaut werden. Dass heißt, dass da etwas auf dem Port lauscht. In dem Zuge wird auch der Connected Callback aufgerufen. Höchstwahrscheinlich lauscht dann da ein brickd. Dass heißt, aber noch nicht dass da auch ein Stack angeschlossen ist. Wenn du jetzt die UID eines der Stack Teilnehmer kennst, dann kannst du einfach für diesen einen Getter aufrufen. Zum Beispiel GetStackVoltage() oder GetIdentity(). Falls keine TimeoutException geworfen wird, dann hat der Teilnehmer geantwortet und ist somit da. Falls eine TimeoutException geworfen wird dann ist da entweder kein Brick(let) mit dieser UID, oder es ist gar kein Stack angeschlossen. Falls du keine UID kennst, dann bleibt dir nur der Enumerate Callback mit Timeout. Wenn es ein "TinkerPing" gäbe würde das genau so funktionieren.

Die Libs an sich reichen zum Ausführen von brickd, aber nicht zum kompilieren. Dafür werden noch die Header Dateien benötigt, die aus *-devel Paketen kommen: sudo yum install libusb1-devel libudev-devel Außerdem fehlt dir GCC. Den kannst du mittels sudo yum groupinstall "Development Tools" installieren, dabei werden auch noch weitere nötige Pakete installiert. Jetzt sollte make alles finden und das Kompilieren funktionieren.

Dir fehlt require 'tinkerforge/bricklet_lcd_20x4' daher ist BrickletLCD20x4 unbekannt.

Neue Bindings funktionieren ohne Probleme mit alten brickd Versionen. Der alte brickd schickt die Disconnect-Probes an den Brick weiter und der Brick ignoriert sie. Da die Disconnect-Probes für USB keinen Sinn machen leitet brickd 2.0.4 sie nicht mehr weiter.

Brick Daemon 2.0.4 NSIS installer automatically installs/updates the WinUSB driver on Windows < 8 Improve callback related log messages Fix wrong log level of startup greeting on Windows Drop incoming disconnect probe requests Fix packet buffer handling in unlikely error case Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.4 NSIS Installer für Windows installiert den WinUSB Treiber auf Windows < 8 Callback-bezogene Logeinträge verbessert Falsches Log-Level für die Startup-Meldung auf Windows korrigiert Eingehende Disconnect-Probes werden verworfen Packet-Buffer-Behandlung im Fehlerfall korrigiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Bindings: C/C++ 2.0.5, C# 2.0.6, Delphi 2.0.8, Java 2.0.6, PHP 2.0.6, Python 2.0.6, Ruby 2.0.6, VB.NET 2.0.2 Enable/Disable Funktionen für die PositionReached und VelocityReached Callbacks zur Servo Brick API hinzugefügt [alle] get/set_i2c_mode (100kHz/400kHz) Funktionen zur Temperature Bricklet API hinzugefügt [alle] Standardtext Funktionen zur LCD 20x4 Bricklet API hinzugefügt [alle] Auto-Reconnect bei Socketfehler korrigiert [C# und VB.NET] Callbacks werden nach einem Disconnect nicht länger ausgeliefert [alle] Race Condition in der Callback-Behandlung korrigiert, die dazu führen konnte, dass der falsche Socket geschlossen wurde [alle, außer PHP] Socketfehler werden beim Senden nicht mehr ignoriert [alle] Spätestens alle 10 Sekunden wird ein Request gesendet, um die Erkennung von WIFI Disconnects zu verbessern [alle] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

Bindings: C/C++ 2.0.5, C# 2.0.6, Delphi 2.0.8, Java 2.0.6, PHP 2.0.6, Python 2.0.6, Ruby 2.0.6, VB.NET 2.0.2 Add enable/disable functions for PositionReached and VelocityReached callbacks to Servo Brick API [all] Add get/set_i2c_mode (100kHz/400kHz) functions to Temperature Bricklet API [all] Add default text functions to LCD 20x4 Bricklet API [all] Fix auto reconnect on socket receive error [C# and VB.NET] Don't dispatch callbacks after disconnect [all] Fix race condition in callback handling that could result in closing the wrong socket [all, except PHP] Don't ignore socket errors on send [all] Send a request at least every 10sec to improve WIFI disconnect detection [all] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

Ja, das Problem ist leider, dass GDB das Programm beim RunError nicht angehalten hat. Ich habe mir auch gerade mal den Code der cthreads Unit angesehen und es hätte nichts geholfen, da an dieser nicht mehr ersichtlich ist was da zu früh aufgerufen wurde. Sorry, für den nutzlosen Vorschlag mit GDB. Ich habe gerade Lazarus auf einem Raspberry Pi (mit aktuellem Raspbian, brickd und brickv) installiert und kann das Problem nicht nachstellen. Meine project1.lpr Datei sieht so aus: program project1; {$mode objfpc}{$H+} uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this }; {$R *.res} begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. Wenn jetzt aus irgendwelchen Gründen UseCThreads nicht definiert ist dann ist cthreads nicht die erste Unit, sondern Interfaces. Wenn das bei dir auch so aussieht, dann teste doch mal ob es hilft, die IFDEFs um cthreads zu entfernen, damit dass dann so aussieht: program project1; {$mode objfpc}{$H+} uses cthreads, Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this }; [...]