photron

Wie AuronX sagt scheitert Reset per Software daran das eben diese Software ja hängt. Loetkolben, der struct.error: unpack requires a string argument of length 2 kommt durch dadurch wenn im brickd ein Packet in mehreren Teilen ankommt. Dass das passieren kann wurde bisher in brickd ignoriert. In brickd Version 1.0.7 ist das jetzt behoben.

Der Syntaxfehler auf Windows ist in Ruby Bindings Version 1.0.1 behoben.

Erstmal zum Syntaxfehler, der tritt nur unter Windows auf und hat mit der Block Syntax zu tun, die ich da verwenden. Unter Linux (Ruby 1.9.2) funktioniert lcd.register_callback BrickletLCD20x4::CALLBACK_BUTTON_PRESSED, do |i| puts "Pressed: #{i}" end unter Windows muss es aber lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| puts "Pressed: #{i}" end sein, warum auch immer. Ich werde das in der nächsten Release der Ruby bindings beheben. Dein eigentliches Problem ist aber folgendes: Die folgenden Zeilen sind kein gültiger Ruby Code: if lcd.register_callback BrickletLCD20x4::CALLBACK_BUTTON_RELEASED == 1 lcd.write_line 1,0, 'released 1' end register_callback erwartet eine Callback ID als int (z.B. BrickletLCD20x4::CALLBACK_BUTTON_RELEASED) und einen Block (do |...| ... end) Du verwendest es aber als wäre es ein Getter, das funktioniert nicht. Eine richtige Verwendung von register_callback sieht z.B. so aus: lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| puts "Pressed: #{i}" end Callback heißt, du übergibst der register_callback Methode einen Block und der wird immer dann ausgeführt wenn ein Callback vom Bricklet ankommt ohne weiteres Zutun von deiner Seite. Callback bedeutet nicht, dass du aktiv in einer Schleife immer wieder fragst ob etwas passiert ist, das nennt mal Polling. Und genau das tut dein Beispiel im Prinzip. Wenn ich deinen Code richtig verstehe willst du solange auf Button 1 reagieren bis Button 2 ein mal gedrückt wurde. Das kann man wie folgt tun: sync = Queue.new # register block for button pressed callback lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| # if it's button 1 write a line if i == 1 lcd.write_line 1, 0, 'pressed 1 ' end end # register block for button released callback lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_RELEASED) do |i| # if it's button 1 write a line if i == 1 lcd.write_line 1, 0, 'released 1' # if it's button 2 push something to the queue so the pop below returns elsif i == 2 sync.push nil end end # block until there is something to pop sync.pop ipcon.destroy Ich benutze hier eine Queue als Synchronisationsmittel damit das Programm so lange am sync.pop steht bis Button 2 gedrückt wurde.

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