photron

Richtig, das Problem bestand in allen Bindings und ich habe gerade den Fix committed. Neue Binding Releases gibt es morgen, denke ich.

Das Problem war hier softwareseitig in brickd. Die aktuelle Brick Daemon Version 1.0.9 funktioniert jetzt auch mit USB 3.0.

Corius, das USB 3.0 nicht funktionierte lag daran, dass die Hersteller wie Intel und NEC/Renesas ihre USB 3.0 Controller nicht unter USB in Windows einsortieren sondern unter IUSB3 bzw NUSB3. Dadurch konnte libusb sie nicht finden, da es USB Hubs unter der USB Kategorie erwartet. Brick Daemon 1.0.9 bringt für Windows eine neue libusb Version mit, die Workarounds für diese USB 3.0 Controller enthält. Dadurch werden Bricks jetzt auch gefunden wenn sie an USB 3.0 angeschlossen sind. The_Real_Black, die Stabilität sollte mit Brick Daemon 1.0.9 jetzt auch besser geworden sein, da ich die Verwendung von libusb in brickd etwas verändert habe um mit hot-unplug besser umgehen zu können.

Brick Daemon 1.0.9 Reduce Windows and Mac OS installer size Avoid race condition when enumerating USB devices on Linux Use more expressive log file name and correct line endings on Windows Don't cancel pending USB transfers to avoid segfault in libusb on Linux Update libusb to make USB 3.0 work on Windows Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.9 Windows and Mac OS Installer Dateigröße reduziert Race Condition beim Auflisten von USB Geräten unter Linux korrigiert Logdatei besser benannt und richtige Zeilenenden unter Windows verwendet Wartenden USB Transfers beim Schließen eines USB Gerätes vorläufig nicht mehr abbrechen um Crash in libusb zu vermeiden libusb aktualisiert, USB 3.0 funktioniert nun unter Windows Downloads: Windows, Linux, Mac OS X

frankiefoo, kannst du brickv mal in gdb starten um zum segfault einen Backtrace zubekommen? Dann können wir sehen was ihn verursacht und stochern hier nicht länger im Trüben.

Der Kreis, der in brickv im Koordinatenkreuz die Position anzeigt, wird gefüllt gezeichnet wenn du den Knopf des Joysticks drückst.

Mal ein Wort zu der Sprach der Website und Dokumentation. Natürlich steht auf unserer großen TODO Liste auch drauf, dass wir die Website und Dokumentation auch in Deutsch haben wollen. Nur das ist nicht mal eben gemacht, dazu muss erstmal alles was noch nicht in Deutsch verfügbar ist übersetzt werden. Wer uns da helfen möchte, ein einfacher Ansatzpunkt ist die API Dokumentation. Diese wird aus Config Dateien generiert. Das Configformat unterstützt schon mehrsprachige Dokumentation. Im Moment ist da nur Englisch drin. Das ganze findet sich auf Github https://github.com/Tinkerforge/generators im Unterverzeichnis configs. Wer also Spass am Übersetzen hat kann sich das Repository clonen, deutsche Dokumentation einfügen und einen Pull-Request machen

Hm, in der Stepper Firmware 1.1.8 steht wirklich 1.1.7 drin. wir korrigieren das. Zum Joystick, es funktioniert also nur der Pressed/Released Callback nicht? Der Rest wie z.B. der Position Callback geht aber?

Der Ausgabewert des Rotary Potis ist fest -150 bis 150. Wenn du da jetzt gerne nur positive Werte haben willst dann kannst du in deinem Programm einfach fest 150 auf den Wert addieren. Dadurch bekommst du einen Wert der von 0 bis 300 geht.

Ich habe das gerade getestet mit Master FW 1.2.3 und Joystick FW 1.1.4 und der pressed Callback funktioniert. Verwendest du am Master beim Testen immer den gleichen Bricklet Port und das gleiche Kabel? Nicht dass da das Problem liegt.

Das mit TThread.CurrentThread habe ich nicht bemerkt, da ich hier mit Delphi XE2 getestet habe. Ist jetzt korrigiert. Die Callback Wrapper sind jetzt protected und virtual.

Bindings: Delphi 1.0.1 TThread.CurrentThread is not supported in Delphi 2007 use Windows.GetCurrentThreadId instead Move callback wrappers from private to protected Download: Delphi

Bindings: Delphi 1.0.1 TThread.CurrentThread ist in Delphi 2007 noch nicht vorhanden, Windows.GetCurrentThreadId wird stattdessen verwendet Callback Wrappers sind jetzt protected statt private Download: Delphi

Wir haben unser Macbook hier gerade geupdated und das Problem reproduziert. Allerdings liegt es nicht am brickd.dmg selbst, sondern daran wie es heruntergeladen wurde. Wenn ich das .dmg mit Chrome oder Safari herunterlade dann tritt dieser Fehler beim Aufruf des Installers auf. Wenn ich aber das .dmg per wget im Terminal herunterlade dann kommt dieser Fehler nicht. Es sieht für mich so aus als würde Mac OS hier die Installation (bzw. die Scriptausführung) aus .dmg's heraus verbieten bei denen es erkennen kann, dass sie heruntergeladen wurden. Denn genau dass steht ja im Kleingedruckten der Fehlermeldung. Ich weiss nicht was man da tun kann.

Ich hab der API Dokumentation der Bricks und Bricklets einen Hinweis auf deren Threadsicherheit hinzugefügt.

Der Zeichensatz des LCD ist fest in einem ROM Baustein auf dem LCD selbst gespeichert. Den können wir leider nicht ändern.

Die sind fertig, ich habe sie gerade released.

Bindings: Delphi 1.0.0 Initial version Download: Delphi

Bindings: Delphi 1.0.0 Initiale Version Download: Delphi

AuronX, ich gebe dir mit deiner Analyse voll recht! Angehängt eine Version in der das Problem behoben sein sollte zum Testen. tinkerforge_java_bindings_1_0_15_add_device_race_fixed.zip

Das ist alles soweit richtig. Es haben sich aber in der letzten Version der Java Bindings einige Detail beim Locking geändert. - Die semaphoreAnswer wurde entfernt und deren Funktion über die responseQueue realisiert. - addDevice ist jetzt thread-safe. Vorher konnten mehrere Threads gleichzeitig addDevice auf eine IPConnection aufrufen und sich gegenseitig die pendingAddDevice Variable überschreiben. Das ist jetzt verbessert. Das hat aber alles hier für diese Problem keine Auswirkung. Wenn das sleep(1) dazuführt, dass Linux einen anderen Prozess scheduled, dann vielleicht ja auch brickd. Und wenn das nicht passiert dann passiert ... keine Ahnung Daher meine Frage ins Blaue, ob das Problem auch auftritt, wenn das Java Programm auf dem R-Pi ist und der brickd auf einem anderen Rechner. Wenn es dann ohne sleep(1) geht heißt dass ... bin ich mir gerade nicht sicher was das dann sagen will. Wie du siehst mehr Fragen als Antworten

Wieso ist das bei einer CPU eines EmbeddedPC notwendig aber nicht bei einem DesktopPC ? Das sollte gar nicht notwendig sein. Von Java und C/C++ Sicht aus macht das sleep da keinen unterschied. Ich nehme mal an dass Java Programm und brickd auf einem Raspberry Pi laufen. Wenn ja mach es einen Unterschied wenn sich das Java Programm mit einem brickd auf einem anderen Rechner verbindet, statt mit dem auf dem Raspberry Pi?

Nein, ich musste immer das Sleep zwischen den addDevice Aufrufen einfügen, daher auch mein Tipp an Masder. Ich kann mir nicht erklären warum das passiert und warum ein Sleep hilft. Hier hatte jemand das gleich Problem unter C auch auf einem Embedded Board: http://www.tinkerunity.org/forum/index.php/topic,322.msg1751.html Da hat dann im Endeffekt ein sleep(0) gereicht. Es ging also nicht darum wirklich eine definierte Zeit zu warten. Bei einem sleep nimmt der Scheduler des OS einen anderen Thread/Process dran und das scheint das Problem zu beheben.

Callbacks werden von einem eigenen Callback Thread der IP Connection ausgeführt. Typischerweise ist es in GUI Frameworks aber so, dass man nur vom Haupt Thread mit dem GUI interagieren darf. Dass heißt du kannst nicht einfach aus Callback heraus mit dem GUI interagieren. Die Probleme die du da siehst kommen daher, dass du es doch tust. Dass es auf 32bit funktioniert halte ich für Zufall. Du musst also etwas zwischen den Callback Thread und dein GUI setzen, dass sich um korrekte Kommunikation zwischen den beiden kümmert. Google fördert für wxWidgets und Python das hier zu tage: http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/ Dort werden wx.CallAfter und das Publish-Subscribe Pattern verwendet um von einem nicht-GUI Thread mit dem GUI zu kommunizieren.