photron

Okay, das Read kann eigentlich nur mit einem Timeout fehlschalgen. Tust du mit dem Brick noch sonst etwas während du das Bricklet flashed? Falls du den Brick stark mit anderen Aufgaben beschäftigst kann es sein, dass das Schreiben des Plugins noch im Gange ist wenn Brickv schon wieder versucht es zu lesen und das Lesen bekommt dann einen Timeout. Falls dein Brick an dem das Bricklet hängt sonst nichts tut, dann kannst du versuchen die Wartezeit zwischen Schreiben und Lesen zu erhöhen. Im Moment sind das 2 Sekunden und eigentlich sollte das auch reichen. In src/brickv/flashing.py in Zeile 438 und 452 steht jeweils ein time.sleep(1). Da kannst du versuchen die Zeit höher zu setzen, z.B. time.sleep(3) oder noch länger.

Dass bcmath benötigt wird steht auch schon ein paar Tage hier: http://www.tinkerforge.com/doc/Software/API_Bindings.html#php Technischer Hintergrund: bcmath wird benötigt um die UID von Base58 in einen 64bit Integer zu konvertieren. Da PHP Zahlen inter als 32bit Integer oder Float darstellt und das beides nicht groß genug ist für einen 64bit Integer.

Wumpus, ich habe gerade die Fehlermedlung beim Bricklet flashen detaillierter gemacht. Du sagtest du hättest deine Version per git geclont. Kannst du die Änderung pullen und noch mal testen? Es ist sehr unerwartet dass das Flashen mal geht und mal nicht geht.

Welche Fehlermeldung bzw. Ausgabe in der Konsole hast du denn wenn das Flashen eines Bricklets nicht funktioniert? Und ja du musst den Brick erst per Erase Knöpfchen gedrückt halten beim Anstecken in den Bootloader bringen. Dann im Flashing Dialog auf dem Brick Tab den Refresh Button klicken. Jetzt sollte in der Serial Port Dropdownbox sowas wie /dev/ttyACM0 stehen. Das ist der Brick im Bootloader. Passenden Firmware auswählen und Save klicken.

Nein, der Code ist nicht für G++ optimiert. Der C Code baucht C99 und Visual Studio kann nur C89. Der Workaround ist bei cl.exe die /TP Option mitzugeben, die dem Compiler sagt den Code als C++ zu kompilieren. cl /TP example.c

"Temperature-IR" mir Bindestrich ist noch ein altes Format. Eigentlich hätte das "Temperature IR" sein sollen, auch in der Firmware. Damit die neuen Bindings die jetzt auch den Device Typ prüfen auch noch mit dem alten "Temperature-IR" funktionieren.

Ich hab mir gerade eine USB3 Steckkarte (LogiLink PC0054) eingebaut und unter Linux (Ubuntu) funktioniert das problemlos.

tex, ich arbeite im Moment nicht an Perl Bindings und mir ist auch noch nicht zu Ohren gekommen, dass sonst jemand daran arbeiten würde. Also kannst du ruhig daran arbeiten wenn dir danach ist. Nic, richtig, die Ruby Bindings sind heute fertig geworden. Als nächstes sind Delphi Bindings dran. Ich werde mir dazu zunächst mal deinen Prototypen ansehen und wohl darauf aufbauen, wenn du nichts dagegen hast

Ruby Bindings sind da! http://www.tinkerforge.com/doc/Software/IPConnection_Ruby.html http://download.tinkerforge.com/bindings/ruby/tinkerforge_ruby_bindings_latest.zip Als nächstes kommen Delphi Bindings, wahrscheinlich aufbauend auf Nics Prototypen: http://www.tinkerunity.org/forum/index.php/topic,444.msg2314.html

Du hast da einen Bug in den Python Bindings gefunden (cannot join current thread). Der ist jetzt in Version 1.0.11 behoben. Das ist aber nicht dein eigentliches Problem, sondern nur ein Nebeneffekt. Teste doch noch mal bitte mit den aktuellen Python Bindings. Was mir noch in deinem Code auffällt: Du registrierst den Callback für den Interrupt bevor du das DC Brick Objekt erzeugst. Du greifst aber im Callback auf die dco Variable zu. Es kann also passieren dass ein Callback kommt bevor die dco Variable richtig gesetzt wurde. Mit anderen Worten: Änder doch mal bitte die Reihenfolge von io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection zu dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) einfach um da auf der sicheren Seite zu sein. Oder prüfe im Callback ob dco != None ist bevor du es verwendest.

In den aktuellen Bindings Versionen (C/C++ 1.0.8, C# 1.1.2, Java 1.0.8, PHP 1.0.3 und Python 1.0.9) wird jetzt auch der Device Typ überprüft. Für einen erfolgreichen AddDevice Aufruf muss jetzt ein Device mit passendem Typ und UID antworten.

Okay, dieses Python 3 Problem ist in Python Bindings 1.0.8 jetzt behoben.

Ich habe jetzt die Beispiele in der TCP/IP Dokumentation noch etwas mehr mit den Typen der Bestandteile eines Packets versehen und ein weiters Beispiel für die kurze UID eines Bricklets hinzugefügt.

Dass das so halb funktioniert wenn du nur Bricklets mit dem zu kurzen Request anfragst hat mit einem Implementierungsdetail der Firmware zu tun und ist im Prinzip zufällig. Es hätte nur für den Master funktionieren sollen und für die Bricklets nie, wegen des zu kurzen Requests. Auch dass das mit den Bricklets nicht mehr geht sobald du einmal den Master angefragt hast beruht auf dem selben Zufall. uint64 -> immer 8 Byte Ich werds etwas deutlich ins Beispiel schreiben im Sinne von "UID 3904673860505581361 as uint64 (0x31 0x37 0x30 0x33 0x30 0x30 0x30 0x36)." Und noch ein Beispiel für ein Bricklet machen. Allgemein gilt: Im TCP/IP Protokoll hat alles feste Größen. Nichts besonderes sollte es mit hex "20" auf sich haben. Auch ist das kein Füller denke ich. Für die Bricks kommt die UID aus dem Mikrocontroller selbst und wir benutzen die einfach, Typischerweise sind dass immer Zahlen bei denen alle 8 Byte der uint64 ungleich 0 sind. Für die Bricklets zählen wir selber eine eindeutige Nummer hoch die dann im EEPROM gespeichert wird. Die erste Bricklet UID war dabei so gewählt das sie in Base58 3-stellig ist und es auch noch eine Weile bleiben wird.

Ohne das jetzt zu testen oder mir über netcat Gedanken zu machen sehe ich hier schon ein Problem. Ein IPConnection.get_stack_id Request Packet hat immer 12 Byte, da die UID fest 8 Byte gross ist. Das heisst [00 FF 06 00 62 57] muss [00 FF 0C 00 62 57 00 00 00 00 00 00] sein.

Ich hab's gerade mal getestet mit Processing 1.5.1 auf Linux und man kann wohl einfach die Java Bindings nehmen. Hier mal was ich getan habe. Mein Processing Sketchbook Verzeichnis ist ~/sketchbook. Darin dann Verzeichnisse anlegen so dass sich ~/sketchbook/libraries/Tinkerforge/library/ ergibt. Darein dann die Tinkerforge.jar, also: ~/sketchbook/libraries/Tinkerforge/library/Tinkerforge.jar Hier ein minimales Proof-of-Concept Beispiel, dass zeigt das zumindest das Import funktioniert: import com.tinkerforge.*; IPConnection ipcon; void setup() { try { ipcon = new IPConnection("localhost", 4223); } catch (Exception e) { } } void draw() { }

Ich hab gerade noch ein Problem mit den Callbacks behoben. Wenn du in einem Callback einen Getter des selben Devices aufgerufen hast konnte das zu einer TimeoutException führen. Das ist in PHP Bindings Version 1.0.2 jetzt behoben. Zu deinem Problem: Dein Script erzeugt in jeder connect_* Funktion eine neue IPConnection. Du solltest initial nur eine erzeugen un die dann in allen connect_* Funktion verwenden. So wie dein Script jetzt ist dispatcht du Callbacks nur auf der zuletzt erzeugen IPConnection der du nur das Temperature Bricklet hinzugefügt hast. Ich denke das erklärt dein Problem

Super. Das ist aber neu, oder? Vor ein paar Wochen habe ich das noch nicht gefunden. Recht neu noch, ja 30. April => http://de.blog.tinkerforge.com/2012/4/30/low-level-protokoll-dokumentierung

PHP hat keine Threads. Das führt erstmal dazu, dass du selbst dispatchCallbacks() aufrufen musst. Wenn du dispatchCallbacks(1) dann werden eingehende Daten vom Socket gelesen und wenn es sich um Callbacks handelt werden diese ausgeführt, falls dafür Funktion registriert wurden. Wenn du dispatchCallbacks(1) aufrufst, dann wird das eine Sekunde lang gemacht und dispatchCallbacks(1) returned auch erst nach einer Sekunde. Das heißt das dein Script an der Stelle für eine Sekunde "steht". Du kannst auch dispatchCallbacks(0) aufrufen, dann werden nur die gerade verfügbaren Daten vom Socket gelesen ohne noch eine Sekunde auf weitere Daten zu warten. Daher empfehlen ich dir dispatchCallbacks(0) aufzurufen. Du solltest weiterhin darauf achten dass du keine lange dauernden Dinge in den Callback Funktionen machst.

Die Callbacks sind in Java per Listener realisiert. Aber die Callbacks werden vom Device ausgelöst. Ein wichtiger Aspekt von Callbacks ist, dass du eben nicht pollen musst, sondern das Device es von sich aus sendet. Das spart deutlich an USB Bandbreite. Aber du kannst natürlich in deinem eigenen Code einen Thread starten und Stack Voltag und Current pollen

Nein, die Callbacks für den Master sind nicht drin, das würde eine Änderung der Firmware benötigen. Ja, Java Bindings Version 1.0.7 beinhaltet JavaDoc (siehe changelog.txt in .zip). Das ist allerdings noch nicht ganz perfekt, da z.B. die einzelnen Funktionsparameter nicht explizit dokumentiert sind. Das gibt der Bindings Generator im Moment nicht her.

Zum Beispiel RealBASIC unterstütz Sockets. Dadurch kann man potentiell RealBASIC Bindings erstellen. Aber nimm das jetzt nicht als Ansage das es in nächster Zeit RealBASIC Bindings geben wird

In Java Bindings 1.0.7 gibts keine unnötigen addListener Methoden mehr.

In C# Bindings Version 1.1.1 gibt es jetzt XML Dokumentation. Auch die anderen Bindings haben jetzt Inline Dokumentation.

Im Moment bin ich mit generellem Aufräumen beschäftigt. Die nächsten Bindings werden für Ruby. Also keine Sorge, dass wir da morgen fertige Delphi Bindings präsentieren. Sind deine Delphi Bindings bisher von Hand programmiert oder hast du auch schon einen Generator gebaut? Am liebsten wäre es mir natürlich wenn ich für die zukünftigen offiziellen Delphi Bindings auf deine bisherige Arbeit aufsetzen könnte