photron

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.