photron

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.

Änder mal private Device lcd; in private BrickletLCD20x4 lcd;

Wenn du WebSockets verwendest hast du aber auch ein PHP Programm auf dem Server das dauerhaft (zumindest länger) läuft und dann kannst du in der Schleife die die Clients bedient auch zwischendurch mal dispatchCallbacks() aufrufen und alles ist gut

Du meinst, dass das erste ipcon_add_device für das TemperatureIR funktioniert die nachfolgenden aber fehlschlagen? Ich hab das hier gerade mal getestet und bei mir funktioniert das ohne Probleme unter Linux mit den C Bindings in Version 1.0.5 (von gestern: http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_1_0_5.zip). Hast du das Problem unter Windows oder mit einer alten Version der C Bindings? Hilft es wenn du zwischen den ipcon_add_device Aufrufen ein sleep von 1 sec einbaust?

Die Bindings prüfen im Moment noch nicht, ob das antwortende Brick von dem Type ist das die Bindings gerade erwarten. Es steht schon auf meiner TODO Liste das zu verbessern. Und wie ArcaneDraconum schon sagt UIDs haben keine feste Länge. Zufälligerweise sind im Moment die UIDs der Bricklets im Auslieferungszustand immer 3-stellig.

Iangillan, ich habe mir gerade mal Scratch angeschaut. So einfach ist die Anbindung zu Tinkerforge dann auch nicht, denke ich. Wie es aussieht kann man nicht so einfach neue Blöcke hinzufügen, ausser man erstellt eine Scratch Modification: http://wiki.scratch.mit.edu/wiki/Scratch_Modification Das ist dann ein eigenständiges Programm das nicht mehr Scratch heißen darf. Das Problem daran ist, dass Scratch in Squeak programmiert ist. Ein einfachere Variante wäre es wohl das Remote Sensors Protocol für Tinkerforge zu implementieren (z.B. in Form eines Proxies zwischen Brick Daemon und Scratch): http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol So weit ich das verstehe könnte man damit die Ausgabewerte der Tinkerforge Sensoren in Scrach per Sensor Block verfügbar machen und in Scratch darauf reagieren. Die Rückrichtung für Aktoren könnte man wohl über Broadcasts bauen. Ob das im Endeffekt ordentlich funktioniert und wie viel Arbeit das ist kann ich gerade nicht einschätzen.

Der Sinn der Callbacks ist, dass du nicht pollen musst um Ereignisse mitzubekommen. Man kommt aber an fasst alle Informationen auch ohne Callbacks. Typischerweise hast du da ein Programm das länger läuft wenn du Callbacks nutzt. Im Rahmen einer Webapplikation wird aber PHP immer nur kurz ausgeführt um die Webseite zu erstellen. Dort hast du kein lange laufendes PHP Programm, daher machen dort Callbacks wenig Sinn. Oder verstehe ich jetzt hier was falsch? In einem lange laufenden Standalone PHP Programm musst du eben dafür sorgen dispatchCallbacks regelmässig aufzurufen, wenn du Callbacks nutzt. Das ist bisher die portabelste Lösung auf die ich bis jetzt gekommen bin. Christian, mir ist nicht ganz klar was du mir mit WinBinder sagen willst. Ich sehe zumindest nichts was dich hindern sollte WinBinder und Tinkerforge in einem Programm zu verwenden.

Und ich schätze immer noch, dass die PHP Bindings diese Woche verfügbar sein werden. Hier mal ein Beispiel Programm, das die Versionsinformation und die aktuelle Position eine Linear Poti Bricklets ausliest. <?php require_once('Tinkerforge/IPConnection.php'); require_once('Tinkerforge/BrickletLinearPoti.php'); use Tinkerforge\IPConnection; use Tinkerforge\BrickletLinearPoti; $host = 'localhost'; $port = 4223; $uid = '7jb'; $ipcon = new IPConnection($host, $port); $lp = new BrickletLinearPoti($uid); $ipcon->addDevice($lp); echo "getVersion():\n"; var_dump($lp->getVersion()); echo "getPosition():\n"; var_dump($lp->getPosition()); ?> Hier die Ausgabe des Programms mit dem PHP Kommandozeilen Tool ausgeführt. Die Minimum PHP Version wird 5.3 sein. Das ganze funktioniert auch mit dem PHP Modul in Apache. getVersion(): array(3) { ["name"]=> string(24) "Linear Poti Bricklet 1.0" ["firmwareVersion"]=> array(3) { [0]=> int(1) [1]=> int(1) [2]=> int(0) } ["bindingVersion"]=> array(3) { [0]=> int(1) [1]=> int(0) [2]=> int(0) } } getPosition(): int(43) Hier noch ein Beispiel mit Callback <?php require_once('Tinkerforge/IPConnection.php'); require_once('Tinkerforge/BrickletLinearPoti.php'); use Tinkerforge\IPConnection; use Tinkerforge\BrickletLinearPoti; $host = 'localhost'; $port = 4223; $uid = '7jb'; $ipcon = new IPConnection($host, $port); $lp = new BrickletLinearPoti($uid); $ipcon->addDevice($lp); function cb_position($position) { echo "position changed: $position\n"; } $lp->registerCallback(BrickletLinearPoti::CALLBACK_POSITION, 'cb_position'); $lp->setPositionCallbackPeriod(20); $ipcon->dispatchCallbacks(-1); ?> Und hier die Ausgabe nach Bewegen des Potis. position changed: 45 position changed: 52 position changed: 56 position changed: 55 position changed: 48 position changed: 43 position changed: 39 position changed: 34 position changed: 30 position changed: 26 position changed: 23 position changed: 21 position changed: 20 Da PHP keine Threads unterstütz und die Workarounds alle recht plattformspezifisch sind muss man selbst dafür sorgen das Callbacks ausgeliefert werden. Dafür ist die dispatchCallbacks Methode der IPConnection da. Der kann man ein Zeitspanne in Sekunden übergeben, die Callbacks ausgeliefert werden sollen bevor dispatchCallbacks returned. -1 wie im Beispiel bedeutet unendlich. Falls ihr Vorschläge oder Kommentare dazu habe dann würde ich sie gerne hören.

Ich pick mir mal nur den Perl Aspekt heraus. Hier gibt es eine Umfrage dazu welche Sprachen als nächstes unterstützt werden soll: http://www.tinkerunity.org/forum/index.php/topic,250.0.html Im Moment sind Bindings für PHP in Arbeit und werden in Kürze verfügbar sein.

Es sollte reichen wenn du _MSC_VER im gesamten Code durch __BORLANDC__ ersetzt. Dann wird das Struct Packing auch für Borland richtig gesetzt und add_device sollte funktionieren.

Okay ich habe mir die Embarcadero RAD Studio XE2 Trial Version installiert. Ich musste ein paar Änderungen am Code vornehmen damit er mit dem Borland Compiler funktioniert. Was hast du getan um den Compiler Fehler wegen PACKED zu beheben? Das eigentliche Problem ist, dass im Moment der Code für Borland Compiler kein Packing für structs aktiviert. Wenn ich das so lasse dann schlägt auch bei mir das add_device fehl. Ich behebe das gerade. Ich denke das wird die Ursache deines Problem sein.

Ersetz mal versuchsweise lcd.write_line(0, 0, 'Hello World') durch lcd.write_line(0, 0, b'Hello World')

Ich verstehe nicht ganz was du mit fehlschlagen meinst. Es hört sich so an als könntest du dein Programm kompilieren und starten und das Problem tritt dann beim Ausführen des Programms auf. Wenn das so ist, dann ist nicht die ws2_32.lib das Problem. Denn wenn die nicht richtig eingebunden wäre dann würde der Compiler (eigentlich der Linker) einen Fehler melden beim Kompilieren. "Add Device" kann ein E_TIMEOUT (-1) zurückgeben, wenn kein Device mit der passenden UID antwortet. Meinst du dass mit "fehlschlagen"? #define UID "aySDPZAhvvd" // Change to your UID // Create device object Master master; master_create(&master, UID); Die UID die du beim Aufruf der create Funktion übergibst muss exakt die sein die der Brick Viewer für den entsprechenden Brick anzeigt. Vielleicht hast du da einen Tippfehler oder die UID aus dem Beispielcode nicht durch die deines Bricks ersetzt?

AuronX, das Problem steht schon auf meiner TODO Liste. AddDevice muss prüfen ob die Device Klasse auch zum antwortenden Brick(let) passt, ansonsten wird es eine Exception werfen. Die Firmware Version ist allerdings nicht eindeutig genug. AddDevice wird das wohl anhand des Device Namens prüfen, da dieser dem "<Name> Brick/Bricklet <Hardware Version>" Muster folgt.

AddDevice wirft eine TimeoutException wenn es kein Device für die gegebene UID antwortet. Christian, die PHP Bindings sind gerade in Arbeit und sollten im Laufe der nächsten Woche fertig werden.

Richtig. Die Function IDs sind bei der TCP/IP Dokumentation bei allen Funktion und Callbacks mit angegeben. Für die Bindings für andere Sprachen sind diese IDs nicht angegeben da sie dort nur intern verwendet werden. Ich verstehe nicht ganz wo du da noch die Function IDs mit angeben willst oder was du noch in eine "Low-Level" Dokumentation stecken willst dass nicht schon in der TCP/IP Dokumentation steckt, oder eigentlich dort hingehört.

C# kann nicht mehrere Werte zurückgeben wie das z.B. Python recht einfach erlaubt. Daher verwenden wir in C# generell out Parameter statt die Ergebnisse direkt zurück zu geben. Bei BrickletHumidity.GetHumidity könnte man hier den einen Wert direkt zurück geben, aber BrickIMU.GetQuaternion hat 4 Rückgabewerte, daher der allgemein Weg über die out Parameter.

Alle Methoden die unsigned Typen verwenden bekommen eine CLS-compliant Überladung. Da die Bindings generiert werden und der Generator den Typ der Parameter kennt (aber nicht den wirklich genutzten Wertebereich) ist dies so einfacher zu lösen. Dies führt auch dazu dass die Bindings für C# im Prinzip so bleiben wie sie jetzt sind und nur für vollständige CLS-Compliance für andere .Net Sprachen erweitert werden.