photron

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

Ich hab die addListener/registerCallback Methoden entfernt für Devices die keine Callbacks haben. Die Callbacks für den Master sind eine gute Idee.

Die TCP/IP Dokumentation ist schon fertig. Hier der generelle Teil http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#ipcon-tcpip und hier z.B. die für das Linear Poti Bricklet http://www.tinkerforge.com/doc/Software/Bricklets/LinearPoti_Bricklet_TCPIP.html#linear-poti-bricklet-tcpip Wenn dir da was fehlt, was nicht verständlich oder detailliert genug ist oder sonstige Probleme damit sind dann sag Bescheid oder frag.

In C# Bindings Version 1.1.0 geben jetzt u.a. Methoden mit nur einem Ausgabewert diesen per return zurück. Die alten Versionen der Methoden mit einem out-Parmeter sind weiterhin verfügbar und als obsolete markiert. Bei mehr als einem Ausgabewerten werden weiterhin all per out-Parameter zurückgegeben. Dank an AuronX, der diese Änderung beigesteuert hat

In Java Bindings Version 1.0.6 ist die Device Klasse jetzt public und abstract.

Es gibt noch kein removeListener Funktion, aber du hast recht so etwas fehlt noch. Bis ich das eingebaut habe funktioniert der Workaround den AuronX beschreibt.

Loetkolben, wie gesagt ist das kein Fehler und die Meldung daher keine Fehlermeldung Zu der 20 Frage: $ python -c 'print str(20.00)' 20.0 Wenn du da ein spezielles Ausgabeformat brauchst dann kannst du einfach das Python Script anpassen. Da du eh schon aus print('Temperature: ' + str(temperature) + ' °C') den Text entfernt hast kannst du das Beispiel ja auch noch weiter anpassen. Immer 2 Nachkommastellen bekommst du so: print('%.2f' % temperature)

Ich werde die Meldung entfernen, den sie hat keinen Mehrwert und stiftet nur Verwirrung wie dieser Thread beweist Außerdem werden Callbacks/Antworten mit unbekannter Function ID eh schon stillschweigend ignoriert.

Du musst da nichts "adden", UID ändern und Beispiel muss funktionieren, tut es ja auch Die Meldung deutet nicht auf ein Problem oder Fehler hin, sondern nur das die IPConnection etwas unerwartetes empfangen hat und es ignoriert hat.

Die Meldung bedeutet, dass die IPConnection eine Nachricht mit Function ID 8 (das ist der Temperature.CALLBACK_TEMPERATURE) vom Stackteilnehmer 2 (das wird wohl das Temperature Bricklet sein) erhalten hat. Aber es kennt keinen Stackteilnehmer 2, daher "unknown Stack ID". Hast du den Brick Viewer auf und den Tab für das Temperature Bricklet aktiv? Dann hat der Brick Viewer den Temperature.CALLBACK_TEMPERATURE Callback für das Bricklet aktiviert und es sendet Callbacks. Wenn du nun dein Script startest dann gibt es ein kleines Zeitfenster zwischen der Erzeugung der IPConnection und dem add_device Aufruf. In dieser Zeit empfängt die IPConnection schon eingehende Nachrichten kennt aber das Temperature Bricklet noch nicht. Du kannst diese Meldung vermeiden indem du brickv oder wer auch immer den Temperature.CALLBACK_TEMPERATURE Callback aktiviert hat schliesst. Oder du kannst die Schleife in das Python Script einbauen, so dass du nicht immer die IPConnection neu erstellst. Aber eigentlich könnte ich diese Meldung auch aus allen Bindings entfernen. Callbacks/Antworten von unbekannten Devices werden eh ignoriert.

Ja, das Problem von Short Reads ist mir auch schon aufgefallen. Es steht auch auf meiner TODO Liste. Und ja im Moment arbeiten alle Bindings so.

Es wird dann auch ein usleep(0) tun. Der Punkt ist dann nicht das Warten an sich sondern, dass das usleep() dazu führt dass der Scheduler einen anderen Prozess dran nimmt. Warum auch immer das einen Unterschied macht. Du sprichst von einem embedded Gerät. Testest du das Programm auch gerade dort, oder auf einem normalen Desktop Rechner? Du hast noch nicht gesagt welche C Bindings Version du verwendest und ob das Problem auch mit der aktuellen Version 1.0.5 auftritt.

Nein. Der RecvLoop liest alles was auf dem Socket ankommt und ruft damit HandleMessage() auf. HandleMessage() unterscheidet dann verschiedene Messages: - AddDevice Antworten werden ausgewertet und das entsprechende Device aktualisiert mit den Informationen über Name, Stack ID etc. - Callback Antworten werden in die callbackQueue gesteckt - Andere Nachrichten für bekannte Devices werden in deren entsprechenden answerQueues gesteckt Der CallbackLoop nimmt Callback Antworten aus der callbackQueue und ruft die entsprechenden Callback Funktionen auf, falls solch eine vom Benutzer registriert wurde. Getter Aufrufe für Devices warten maximal 2,5 sec bis in ihrer answerQueue etwas angekommen ist.

Beide Threads laufen durch. RecvLoopFlag ist normalerweise True und wird beim destroy auf False gesetzt, damit man die Threads sauber abbrechen kann. Also steht da im Normalbetrieb ein while(True). Dass du im Debugger da nur was passieren siehst wenn du Devices ansteckst ist erwartet. Beim Anstecken schickt dir brickd eine Enumerate Message. Der socketStream.Read() Aufruf blockiert bis Daten zu lesen sind. Also steht der Thread die meiste Zeit in der Read() Methode wenn keine Daten übertragen werden.

Es muss auch ohne die sleeps funktionieren und das tut es hier auch. Ich hatte das vorgeschlagen weil jemand ein ähnliches Problem hatte und ihm sleeps geholfen haben. Das war allerdings vor meiner Zeit. Tritt das Problem auf Linux, Windows oder Mac OS auf? Tritt das Problem auch mit der aktuelle Version 1.0.5 der C Bindings auf? Nur wenn ich das Problem reproduzieren kann kann ich es auch beheben

Der RecvLoop läuft dauerhaft, liest alles was am Socket ankommt und behandelt es passend. Der CallbackLoop ist dafür da die Callbacks auszuführen, so dass man aus Callbacks heraus auch noch Getter der Devices aufrufen kann. Würden der RecvLoop die Callbacks ausführen würde dieser ja in der Zeit keine eingehenden Packages mehr annehmen können und wir hätten ein Deadlock, da die Antwort des Devices auf den Getter Aufruf nicht gelesen würde. Das ganze kommuniziert miteinander über thread-sichere Queues.

Das wäre in der Tat eine Möglichkeit Javascript Bindings zu machen. Aber warum so kompliziert? Wenn ich in Javascript schon WebSocket habe dann kann ich auch gleich von Javascript aus direkt mit brickd reden.

Das Problem ist jetzt auch in Version 1.0.5 der C Bindings behoben.