photron

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.

AuronX, danke für den Hinweis. Wir können die C# Bindings CLS-compliant machen, denke ich. Da C# unsigned Typen unterstützt würden wir diese ungern durch die nächst größeren signed Typen ersetzen (so wie das in den Java Bindnings ist, weil es da nicht anders geht). Daher wäre eine Idee, dass jede Methode die nicht CLS-compliant ist einen CLS-compliant Überladung bekommt. Zum Beispiel für BrickIMU würde aus public void SetAccelerationPeriod(uint period); dann [CLSCompliantAttribute(false)] public void SetAccelerationPeriod(uint period); [CLSCompliantAttribute(true)] public void SetAccelerationPeriod(long period); In der Hoffnung, dass das so geht (ich hab's noch nicht getestet) und z.B. in VB.net die CLS-compliant Variante aufgerufen wird und diese sich nicht mit Der Überladung in die Quere kommt. Falls nicht würde die CLS-compliant Variante noch einen Anhang an den Methodennamen bekommen. Siehst du sonst noch Probleme außer die unsigned Typen?

AuronX, ich gebe dir recht und habe die Device Klasse in eine eigene Datei verschoben. Die nächste Release der Java Bindings wird dann eine public Device Klasse haben.

io.get_port() funktioniert hier bei mir. Als erstes solltest du einmal die Firmware des Bricklets neu flashen und dann noch mal testen. Ansonsten hab ich keine anderen einfache Erklärung für das Problem zur Hand.

Das Device nicht public ist aber als Parameter in addDevice verwendet wird ist richtig und es ist ganz normal und erwartet dass das so in Java funktioniert. Das funktioniert da Device package Visibility hat und daher können alle Brick und Bricklet Klassen im com.tinkerforge Package davon erben. Die Brick und Bricklet Klassen selbst sind public und Objekte davon können daher an addDevice übergeben werden. Aber es spricht nichts dagegen Device public zu machen. Allerdings kann man nur einen public Klasse pro .java Datei haben. Eine mögliche Lösung wäre die Device Klasse in eine Device.java auszulagern. Aber eigentlich wollen wir die IPConnection (und dazu gehört das Device) in einer Datei haben. Was ich aber recht einfach tun kann ist die Device Klasse als innere Klasse in IPConnection Klasse zu machen, so dass sie über IPConnection.Device public verfügbar ist.