Jump to content

photron

Administrators
  • Content Count

    2733
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by photron

  1. 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.
  2. 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.
  3. Das Problem ist jetzt auch in Version 1.0.5 der C Bindings behoben.
  4. Änder mal private Device lcd; in private BrickletLCD20x4 lcd;
  5. 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
  6. 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?
  7. 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.
  8. 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 Scr
  9. 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
  10. 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()
  11. 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.
  12. 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.
  13. 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.
  14. Ersetz mal versuchsweise lcd.write_line(0, 0, 'Hello World') durch lcd.write_line(0, 0, b'Hello World')
  15. 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 M
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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
  22. 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.
  23. 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.
  24. 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
×
×
  • Create New...