photron

brickd v2 beta3 für Mac OS X kommt jetzt wieder mit der passenden libusb. Unter Windows schreibt brickd jetzt Warnings und Errors ins Event Log.

Das steht noch auf der TODO Liste. IIRC hatte ich mich damals davon überzeugt, dass es zur Unicodebehandlung unter Delphi und Free Pascal nichts Einheitliches gab. Hab' da gerade noch mal gegooglet und UnicodeString (was es aber wohl erst ab Delphi 2009 gibt) und WideString gefunden. Keine Ahnung warum ich mich damals vom Gegenteil überzeugt hatte. Damit ist das auf der TODO Liste nach oben gerückt.

Das da steht brickd würde libusb 2.0.0 benötigen verwundert mich, es gibt keine libusb 2.0.0.

Müssen bei der Migration auf das neue Protokoll im eigenen Code Anpassungen vorgenommen werden ? Ja. Das betrifft hauptsächlich die IPConnection und die Signatur von Callbacks. Vergleiche v1 mit v2 des Temperature Bricklet Callback Beispiels. Standardmässig schreibt brickd unter Windows kein Logfile, sondern wird Errors und Warnings ins Event Log schreiben. "wird" weil die aktuelle Beta das noch nicht tut. Wird brickd allerdings mit --debug Option gestartet dann schreibt er ein Logfile mit vollem Debug Level in eine brickd.log Datei ins gleiche Verzeichnis in der auch brickd.exe liegt. Um brickd mit --debug Option zu starten muss er über die Computerverwaltung beendet, als Startparameter --debug angegeben und wieder gestartete werden. Es wird dann auch noch die Möglichkeit geben, das Logging genauer über eine Konfigurationsdatei einzustellen. Im Moment kann das nur über die --debug Option gesteuert werden.

Das Log reicht mir schon, kein weiteres mit LOG_LEVEL_DEBUG bzw --debug nötig. Das Problem tritt nur auf, wenn mehreren Clients gleichzeitig eine Verbindung zu brickd haben. Dabei kann es passieren, dass die Clients in einer anderen zeitlichen Reihenfolge die Verbindung trennen verglichen mit der Reihenfolge des Verbindungsaufbaus. Das passiert in deinem Fall. Warum dass gerade mit dem Reset des Master Bricks zusammen fällt ist mir nicht klar. Dadurch kommt die Datenhaltung in brickd durcheinander. brickd fällt in eine Schleife in der er versucht einen Client aus der Liste der verbundenen Client zu entfernen, scheitert aber durch den Fehler in der Datenhaltung. Diesen Bug habe ich gerade behoben. Auf github findet sich jetzt die korrigierte Version. Zum Testen hab ich ein Debian AMD64 Package angehängt. Um Windows und Mac OS X Installer neuzubauen habe ich gerade nicht die dafür eingerichteten PCs zur Hand. brickd-2.0.0_eda6a29a188cd8ce667afa9cdabbdef47f75f27b_amd64.deb

Mac ist hier die wichtige Information. Brick Viewer 1.1.17 für Mac OS X kommt jetzt mit einer älteren Qt Version (4.7). Die neuere Qt Version (4. hat ein Problem, dass dazu führt, dass die Graphen nicht dargestellt werden. Mit Qt 4.7 tritt diese Problem nicht auf und die Graphen funktionieren. Die UIDs sind Base58 enkodiert, eine "1" entspricht dezimal 0 und wenn der Brick eine 0 als UID vom Bricklet EEPROM liest kann er nicht unterscheiden, ob an dem Bricklet Port jetzt wirklich ein Bricklet mit UID 0 steckt oder kein Bricklet abgeschlossen ist. Denn wenn der Brick versucht ein nicht existentes Bricklet auszulesen bekommt er auch eine 0 als UID zurück. Daher nimmt der Brick an, dass an Ports wo er UID "1" liest kein Bricklet angeschlossen ist und daher taucht ein Bricklet mit UID "1" nicht im Brick Viewer auf. Eigentlich liefern wir alle Bricklets mit einer voreingestellten UID ungleich "1" aus. Wie da bei dir eine "1" reingekommen ist ist mir unklar.

Brick Viewer 1.1.17 Mitgeliefertes Qt Version auf 4.7 zurücksetzen um auf Mac OS X ein Problem mit der Darstellung von Graphen zu beheben Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.17 Downgrade packaged Qt to 4.7 on Mac OS X to fix a graph rendering problem Downloads: Windows, Linux, Mac OS X

Ja. Mir ist die Frage nicht klar. Wenn du einen auf Eingang gestellten Pin mit GND/"-" verbindest ziehst du den Eingang auf Low und löst einen Interrupt aus, wenn der Pin dafür konfiguriert ist.

Der Servo Brick selbst ist dann über USB versorgt. Die Servo Motoren müssen entweder über den schwarzen Eingang auf dem Servo Brick versorgt werden, oder über eine Step-Down Power Supply. Die Step-Down Power Supply speist 5V und die extern angelegte Spannung in den Stack ein. Diese extern angelegte Spannung wird vom Servo Brick für die Servo Motoren verwendet, wenn keine Spannung am schwarzen Eingang des Servo Bricks selbst anliegt. Richtig, alle Bricks können für sich über USB verwendet werden. Einen Master Brick brauchst du nur, wenn du einen Stack baust, oder Extensions (RS485, WIFI, etc) verwenden willst. Die Step-Down Power Supply ist hier speziell, die funktioniert mit jedem Brick auch einzeln.

Das sollte potentiell auch mit 5m Kabel funktionieren, da auf dem Servo Brick ein extra Treiber IC für die 7 Ausgänge sitzt.

Bindings: C/C++ 1.0.24, C# 1.1.16, Delphi 1.0.8, Java 1.0.22, PHP 1.0.17, Python 1.0.25, Ruby 1.0.14 Add API for Voltage/Current Bricklet Add API for GPS Bricklet Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 1.0.24, C# 1.1.16, Delphi 1.0.8, Java 1.0.22, PHP 1.0.17, Python 1.0.25, Ruby 1.0.14 API für Voltage/Current Bricklet hinzugefügt API für GPS Bricklet hinzugefügt Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Brick Viewer 1.1.16 Add plugin for Voltage/Current Bricklet Add plugin for GPS Bricklet Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.16 Plugin für Voltage/Current Bricklet hinzugefügt Plugin für GPS Bricklet hinzugefügt Downloads: Windows, Linux, Mac OS X

Hört sich alles soweit richtig an. Brick scheint grundsätzlich zu funktionieren (LED und Lauflicht leuchten), Brick Daemon scheint so weit zu funktionieren, da sich der Brick Viewer connecten kann. Brickd meldet Errors und Warnings im Application Event Log, das befindet sich in der Computer Verwaltung (da wo auch die Services aufgelistet sind) und dann unter "System Tools > Event Viewer > Application". Stehen dort Einträge mit Source Brickd? Wenn ja, was stehen da für Fehlermeldungen?

Meinst du dass die WIFI Extension selbst als Access Point arbeitet und du dich dann dazu verbinden kannst? Ja das geht: http://www.tinkerforge.com/doc/Hardware/Master_Extensions/WIFI_Extension.html#access-point-modus-und-ad-hoc-modus

Es wird als Ersatz für die Funktionalität von ipcon_join_thread dann ipcon_wait und ipcon_unwait geben. ipcon_wait blockiert so lange bis ipcon_unwait aufgerufen wird. Intern wird dazu eine Semaphore benutzt, ipcon_wait zählt runter und ipcon_unwait zählt rauf.

Wen da "!Master Brick" im Gerätemanager steht dann ist höchstwahrscheinlich der Treiber nicht installiert.

Den eigentliche Treiber (WinUSB.sys) liefern wir gar nicht aus, sondern den hat Windows schon selbst. Wir liefern im Prinzip nur die .inf Datei die Windows sagt, dass ein Brick ein WinUSB Gerät ist und Windows nutzt dann den passenden Treiber dafür. Zusätzlich liefern wir noch zwei notwendige Hilfsdateien (WdfCoInstaller01009.dll und winusbcoinstaller2.dll) die aber auch von Microsoft selbst kommen. So dass ich nicht weiß was ich da jetzt tun könnte/sollte. Zu DPC_WATCHDOG_VIOLATION findet man, dass das in Windows 8 vom neuerdings aktiven DPC/ISR Watchdog kommt der Treiber überwacht und einen BSOD auslöst wenn Treiberfunktionen zu lange dauern. Ich bin mir nicht sicher ob Microsoft sich da einen Gefallen getan hat. Meine Empfehlung ist, statt den Treiber der brickd beiliegt zu verwenden, den aktuelleren und signierten Treiber per Zadig zu installieren. Zadig bringt neuere Versionen von WdfCoInstaller01009.dll und winusbcoinstaller2.dll mit, WinUSB.sys kommt weiterhin von Windows selbst. Mit Firmwareversion 2.0 die in kürze für alle Bricks erscheinen wird ist dann unter Windows 8 keine Treiberinstallation mehr nötig. Da sich die Bricks dann selbst als WinUSB Gerät ausgeben können und die .inf Datei nicht mehr nötig ist. Bricks werden dann von Windows 8 automatisch erkannt und der passenden Treiber automatisch geladen, wie man dann z.B. von USB Sticks kennt. Damit sollte sich dann auch dieses Problem erledigt haben.

Den Brick Daemon auf dem Rechner brauchst du nur wenn der Brick über USB angeschlossen ist. Bei WIFI und Ethernet Extension ist kein brickd auf dem Rechner nötig da die TCP/IP Verbindung direkt zum Brick geht. Es ist da also keine Erweiterung des brickd notwendig

Sure, this is possible. You have two somewhat unrelated problems/tasks here: [*]Getting the illuminance value from the Ambient Light Bricklet [*]Writing the illuminance value into your database For the first task you can find example code in our API documentation: http://www.tinkerforge.com/doc/Software/Bricklets/AmbientLight_Bricklet_Java.html For the second task your Java program gets the illuminance value from the Ambient Light Bricklet and sends it to your webserver. How this is done in detail is up to you.

Das Problem lag daran, dass ich nur mit gcc und nicht g++ getestet habe. Ist jetzt behoben in git. Danke für den Hinweise.

Welche Fehler hast du denn ohne -fpermissive bekommen? Waren das Fehler in den C/C++ Bindings? Dann hätte ich sie gerne gewusst um das verbessern zu können.

Ah. Du hältst mit pause() den Haupt-Thread an und arbeitest dann aus den Callback heraus. Ja das ist okay so Du hast also ipcon_join_thread so verwendet wie es gedacht war. Im Moment haben wir in Protokoll 2.0 keinen gleichwertigen Ersatz dafür. Deswegen meinte ich eben auch schon: