photron

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 USB-Port müsstest Du beim Carambola wohl auf jeden Fall nachrüsten - ausser wenn TF vielleicht irgendwann den brickd so erweitert, dass er (in Verbindung mit der Ethernet Extension) auch direkt über das LAN-Kabel kommuniziert.

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.

Nur beim Compilen von meinem Programm musste ich beim g++ das Flag -fpermissive angeben.

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:

Müssen wir mal gucken was wir da machen können um Programme die ipcon_join_thread verwendet haben weiter zu unterstützen.

Mir ist nicht klar wie du pause() verwenden willst hier. Du solltest aber definitiv nicht pause() in einem Callback aufrufen, vor allem nicht im Disconnected Callback, weil du damit den Callback Thread anhältst und der sich so dann nicht um das Auto-Reconnect kümmern kann.

Du kannst generell nicht in einem Callback auf einen anderen warten, da es nur einen Callback Thread gibt.

ipcon_join_thread habe ich benutzt um mein Program zu beenden wenn der brickd gestorben ist. Wie merke ich das jetzt ?

Ah, trickreich! Wenn brickd stirbt, dann reist die TCP/IP Verbindung ab. Dafür gab es vorher keinen richtigen Mechanismus das mitzubekommen. Dafür gibt es jetzt den Disconnected Callback:

void disconnected(int disconnect_reason, void *user_data) {
    printf("disconnected: %d\n", diconnect_reason);
}

ipcon_register_callback(ipcon, IPCON_CALLBACK_DISCONNECTED, disconnected, NULL);

disconnect_reason kann REQUEST, ERROR oder SHUTDOWN sein. Bei REQUEST hast du explizit vorher ipcon_disconnect aufgerufen. Bei SHUTDOWN hat die Gegenseite die Verbindung geschlossen. Bei ERROR ist ein Fehler aufgetreten.

Standardmäßig ist Auto-Reconnect an, so dass die IPConnection in diesem Fall automatisch versucht die Verbindung wieder aufzubauen, nachdem sie dir den Callback über den Disconnect zugestellt hat. Das kann über ipcon_set_auto_reconnect kontrolliert werden.

ipcon_set_auto_reconnect(ipcon, false) und ipcon_disconnect brechen ein laufendes Auto-Reconnect ab. Und ipcon_get_connection_state verät dir den aktuellen Zustand der TCP/IP Verbindung.

Als gegenstück zum Disconnected Callback gibt es den Connected Callback, der mitteilt dass die TCP/IP Verbindung aufgebaut wurde.

Die generellen API Änderungen sind hier beschrieben:

http://www.tinkerforge.com/doc/Protocol_20.html

Es wird auch noch eine Portierungsanleitung geben, hier mal die wichtigsten Punkte:

Die host und port Parameter sind von sind von ipcon_create nach ipcon_connect gewandert. ipcon_create stellt nicht mehr die TCP/IP Verbindung her, dass tut jetzt ipcon_connect. ipcon_connect startet auch erst die internen Threads.

ipcon_enumerate nimmt kein Callback Parameter mehr, dafür ist jetzt ipcon_register_callback da. Es gibt neue Callbacks neben Enumerate, die darüber informieren wenn die TCP/IP hergestellt und getrennt wurde.

<device>_create nimmt jetzt neben der UID noch die IPConnection als Parameter und es gibt kein ipcon_add_device mehr.

<device>_register_callback nimmt jetzt ein user_data Parameter und alle Callback Signaturen sind um ein user_data Parameter erweitert. Der user_data Wert der bei <device>_register_callback übergeben wird wir dann an den registrierten Callback weitergereicht.

Die meiste Information aus <device>_get_version ist jetzt im neuen Enumerate Callback untergebracht. Es gibt statt <device>_get_version jetzt nur noch <device>_get_api_version.

Mit <device>_set_response_expected kann man für Setter aktivieren, dass der Brick eine Antwort schickt um sicher gehen zu können, dass der Setter auch angekommen ist.

ipcon_discconnect wartet standardmässig auf das Beenden der internen Threads. Da die internen Threads jetzt nicht mehr durchlaufen sondern in ipcon_connect erzeugt und in ipcon_disconnect beendet werden funktioniert ipcon_join_thread nicht mehr wie vorher und wurde entfernt. Falls du einen solchen Syncronisierungsmeachnismus benötigst musst du ihn die jetzt selber bauen. Interne verwendet die IPConnection solche Dinge weiterhin. Müssen wir mal gucken was wir da machen können um Programme die ipcon_join_thread verwendet haben weiter zu unterstützen.

Schau dir auch die aktualisierten Beispiele an.

Ich vermute das die letzte Mail so zu verstehen ist, das die Bindings noch kein 2.0 unterstützen ?!

C/C++ Bindings im git sind jetzt für Protokoll v2 umgebaut.

Brick Viewer 1.1.15

• Support for LCD 20x4 Bricklet hardware version 1.2
  

Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.15

• Support für LCD 20x4 Bricklet Hardware Version 1.2
  

Downloads: Windows, Linux, Mac OS X

Entweder im Makefile die Variablen so setzen:

LIBUSB_CFLAGS := -I/mnt/clfs/cross-tools/include/libusb-1.0
LIBUSB_LDFLAGS := -L/mnt/clfs/cross-tools/lib
LIBUSB_LIBS := -lusb-1.0

oder make so aufrufen:

make WITH_LIBUDEV=no LIBUSB_CFLAGS=-I/mnt/clfs/cross-tools/include/libusb-1.0 LIBUSB_LDFLAGS=-L/mnt/clfs/cross-tools/lib LIBUSB_LIBS=-lusb-1.0

Ich habe gerade das Makefile so geändert dass du jetzt make WITH_LIBUDEV=no ausführen kannst und einen brickd ohne libudev bekommst. Vorher einmal make clean, damit die neuen Rules auch wirken.

was muss ich da im source anpassen?

Um was zu tun? Ohne libudev zu compilieren?

Ich schätze man muss hier mit Bitshifting arbeiten aber da kenn ich mich leider überhaupt nicht aus ...

Richtig, $interruptMask und $valueMask sind Bitmasken. Jedes Bit darin entspricht einem Pin. Mit dem &-Operator kannst du Bits testen:

if ($interruptMask & (1 << 3)) {
    if ($valueMask & (1 << 3)) {
        echo "Interrupt: Pin 3 is high";
    } else {
        echo "Interrupt: Pin 3 is low";
    }
}

(1 << 3) bedeutet die 1 um 3 stellen nach links shiften, das ist dann Pin 3 bzw. der 4te Pin. Das mit $interruptMask verundet ergibt einen Wert ungleich 0 (den PHP als true interpretiert) wenn in $interruptMask auch das Bit für Pin 3 gesetzt ist. Der gleichen Test funktioniert auch mit $valueMask um zu bestimmen ob es Interrupt für high oder low ist.

Wenn jetzt mehrere Pins involviert sind funktioniert das immer noch, da du mit diesem Muster einzelnen Pins testen kannst unabhängig voneinander:

for ($pin = 0; $pin < 8; $pin++) {
    if ($interruptMask & (1 << $pin)) {
        if ($valueMask & (1 << $pin)) {
            echo "Interrupt: Pin $pin is high";
        } else {
            echo "Interrupt: Pin $pin is low";
        }
    }
}

Unter Linux benutzen wir libudev um uevents vom Kernel zu bekommen, die z.B. dann ausgelöst werden wenn USB Geräte ab- oder angesteckt werden. So bekommt brickd damit, dass ein Brick ab- oder angesteckt wurde.

Unter Windows benutzten wir dafür die DeviceNotifcation Funktionalität der WinAPI.

Unter Mac OS X benutzten wir dafür den IONotificationPort von IOKit.

Essentiell ist das nicht und brickd könnte auch ohne, nur kennt brickd dann halt nur die USB Geräte die da waren als brickd gestartet wurde.

Das sollte nach aktuellem Stand klappen, ja.

Allerdings habe ich auch festgestellt, das die Bindings noch etwas auf Vervollständigung warten. Zumindest sind Definition und Deklaration von ipcon_enumerate schon unterschiedlich. Da warte ich doch mal die nächste Release ab.

Die C Bindings habe ich gerade in Arbeit. Sollten heute soweit fertig werden, dass man sie verwenden kann.

Okay, deren Nummerschema ist anders als ich erwartet hatte.

...eigentlich sind hier alle nötigen Schritte beschrieben, wenn auch etwas knapp.

Ich muss vor dem generate_makefile noch ein paar Pfade setzen:

 

export CMAKE_C_COMPILER=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi-gcc
export CMAKE_CXX_COMPILER=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi-g++
export PATH=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/:${PATH}

Es reicht eigentlich das bin Verzeichnis vor den PATH zu hängen, cmake findet dann die ARM Compiler selbst ohne, dass du CMAKE_C(XX)_COMPILER setzen musst.

HotPizzaBox, meinst du "Sourcery CodeBench Lite 2012.09-63 for ARM EABI" mit den "Sourcery CodeBench gcc 4.7.2 (?) (Release 13. November 2012)"? Ich frage, weil ich für eine "November 2012" Release eine andere Nummer als 2012.09-63 erwarten würde, denn 09 sieht so nach dem Monat aus.

Ich füge gerade auf der Firmware und Plugins Seite eine Liste über verschiedene Compilerversionen ein mit Angaben darüber ob diese Version richtig funktioniert.

Eines meiner Probleme hat sich bisher nicht verbessert, wenn der Stack einen Reset macht, muss der brickd gestoppt und neu gestartet werden um die Kommunikation wieder aufzubauen. (Muss ich wohl doch über ein hotplug2 Skript lösen)

Hotplug sollte brickd über libudev mitbekommen. Funktioniert udev möglicherweise auf dem OpenWrt nicht richtig? Du solltest in der brickd Logausgabe eigentlich Zeilen wie diese haben:

2012-12-04 13:47:07.439303 <D> <udev.c:74> Received udev event (action: remove, dev node: /dev/bus/usb/003/002, sys name: 3-2)

2012-12-04 13:47:10.455950 <D> <udev.c:74> Received udev event (action: add, dev node: /dev/bus/usb/001/016, sys name: 1-2)

Dafür belegt er aber nur noch 5% statt 50% des verfügbaren Speichers.

Da merkt man, dass es kein Python, sondern C ist

Nic, eigentlich sind hier alle nötigen Schritte beschrieben, wenn auch etwas knapp. Wo ich dir recht geben muss, da fehlt noch eine Art FAQ über mögliche Probleme und deren Lösungen.

HotPizzaBox, wie flashed du die Firmware? Genauer gefragt wie bringst du den Brick in den Bootloader Modus? Erase gedrückt halten und dann USB anstecken? In dem Fall schaft brickv es nach dem Flashen nicht den Brick richtig neuzustarten. Dann muss du einmal USB ab- und wieder anstecken, damit der Brick richtig neustartet.

Warum das passiert ist nicht ganz klar, wenn du allerdings Reset drückst, während Erase gedrückt gehalten wird und USB angeschlossen ist, dann funktioniert das Neustarten durch bríckv nach dem Flashen.

Ich dachte ich hätte das in der Dokumentation schon abgeändert, scheint nicht der Fall zu sein

Was musstest du denn ändern am Makefile? Dann kann ich das schon mal einbauen.

Bezüglich libudev sollte pkg-config eigentlich alle nötige Pfade liefern.

Auf github findet sich auch der Source Code für alle Firmwares und Plugins. Diese sind schon grundsätzlich für Protokoll 2.0 umgebaut. Es fehlen noch ein paar Kleinigkeiten und Authentication.

Wir haben noch keine vorkompilieren Firmwares/Plugins auf unserm Server aber im Source Code ist Protokoll 2.0 soweit fortgeschritten, dass du es schon testen kannst wenn du brickd und brickv sowie die Firmwares und Plugins aus dem aktuellen Source Code kompilierst und deine Bricks und Bricklets neu flashed.