photron

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.

Bindings: C/C++ 1.0.17 Add support for big endian systems Download: C/C++

Bindings: C/C++ 1.0.17 Support für Big Endian Systeme hinzugefügt Download: C/C++

So, die Änderungen sind jetzt auch in C/C++ Bindings 1.0.17.

Hört sich an als ob du es nicht in der richtigen Reihenfolge machst. Einmal genau Schritt für Schritt: - Master ist noch nicht am Rechner angeschlossen - brickv läuft und Connect Knopf wurde geklickt (dies verbindet brickv mit brickd, der Connect Knopf hat nichts mit der Verbindung zum Master direkt zu tun) - Bricklet an Master anschliessen (Master ist immer noch nicht per USB an Rechner angeschlossen) - jetzt erst den Master mit den Bricklets dran per USB anschliessen - der Master und die Bricklets tauchen nach einem Moment in brickv auf Die Farbe der Brickletkabel macht für die Funktion keinen Unterschied.

Wie schliesst du die Bricklets denn an? Du musst zuerst die Bricklets an den Master anschliessen und dann erst den Master an USB. Dass das schwarze Kabel am Distance IR ist definitiv nicht normal

Das kommt davon wenn man's nicht testet Ich hatte einige Stellen übersehen. Hier jetzt Version 2, da sollte ich jetzt alles erwischt haben. tinkerforge_c_bindings_1_0_16_endian_2.zip

Das ist das nicht-GUI Thread Problem das ich meinte. Du kannst mit dem GUI nicht aus einem nicht-GUI Thread interagieren. Du brauchst einen Mechanismus mit dem du vom Callback Thread sauber mit dem GUI Thread interagieren kann. In Qt kann man Signal/Slot dafür benutzen, GTK wird da auch eine Lösung für haben.

Du meinst einzelne Bricklets oder Bricks am Stack an- und abstecken, also nicht USB? Es gibt kein Hotplug im Stack. Enumerate ist nur für USB an- und abstecken.

Exakt das ist die Aufgabe des Enumerate Callbacks. Nehmen wir mal dein GUI aus der Gleichung raus. Der Preview liegt eine Example.pas bei die die Verwendung des Enumerate Callbacks demonstriert. Teste doch mal bitte diese Programm. Es sollte dich über das an- und abstecken von Bricks an USB informieren.

Du sagtest du reagierst in deinem Programm dynamisch auf ab- und anstecken von Bricks an USB mittels des Enumerate Callback. Im Falle des Absteckens kommt ein Enumerate Callback mit isNew = false. Ich rate jetzt ins Blaue und sage, dass du im Callback dann die GUI Elemente für diesen Brick wieder entfernst. Oder vielleicht es auch nur aus deinem Listenfenster entfernst. Der Backtrace den glibc da ausgibt besagt, dass dein Programm gtk_widget_queue_draw aufruft. Dieser Aufruf führt im Endeffekt zu einem "double free or corruption". Typische Ursache für so etwas ist, dass du eine GTK Funktion auf einen ungültiges Pointer aufgerufen hast, oder dass GTK es dier hier übel nimmst dass du aus einem nicht-GUI Thread (dem Callback Thread) mit dem GUI interagierst.

Hier C/C++ Bindings die jetzt Big Endian richtig behandeln sollten. tinkerforge_c_bindings_1_0_16_endian.zip

Wenn brickd gudev nicht importen kann dann steht "Could not import gudev. Disabling USB hotplug" im Log als Warning. Du scheinst aber laut Log python-gudev zu haben, denn im Log steht ganz am Ende "Removed USB device". Dies wird ausgegeben wenn brickd von udev gesagt bekommt, dass ein USB Device entfernt wurde. Sieht so aus, als würde udev also grundsätzlich funktionieren, aber es brickd nicht darüber informieren wenn ein USB Device dazugekommen ist. Fraglich ist jetzt warum das passiert. Ich würde die Ursache auf udevs Seite sehen.

Wie und welche Verbinding trennst du und wie sieht der Fehler bzw die Meldung aus?

Ich habe jetzt in den aktuellen Version aller Bindings sichergestellt, dass der Callback Thread beendet ist bevor der Receive Thread beendet wird. Damit kann das beschriebene Problem nicht mehr auftreten.