photron

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.

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.

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.

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) 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.

Es scheint da ein Problem mit dem BeagleBoard und USB im Zusammenhang mir den Bricks zu geben. Ich bekomme die Details gerade nicht mehr ganz auf die Reihe. Ich hatte vor einer weile Mal versucht eine Brick an einem BeagleBoard C4 zum Laufen zu bekommen. Es ist dann an einem Problem mit USB 1.1 (OHCI) vs 2.0 (EHCI) gescheitert. Ich habe dann noch versucht den Kernel passenden Treibern zu kompilieren, sodass EHCI richtig funktioniert (Bricks sind USB 2.0 Full Speed), weil ich das als Problemquelle ausgemacht hatte. Brachte aber nichts, oder ich habe es nicht richtig hinbekommen, kann ich mich nicht mehr errinnen Abhilfe hat es dann gebracht einen USB Hub zwischen BeagleBoard und Brick zu stecken. Vielleicht hat dein BeagleBone ähnliche Probleme.

Brick Daemon v2 wird in dem Sinne stateless sein, dass es keine State gibt der zwingend notwendig ist. Du kannst brickd also im laufenden Betrieb neustarten und das ganze funktioniert weiter, es gehen potentiell nur ein paar Packets verloren. Brick Daemon v2 merkt sich immer noch Dinge um effizienter arbeiten zu können. Zum Beispiel merkt er sich (wie ein Switch das auch tut) über welches USB Geräte welche UIDs zu erreichen sind, um gezielt senden zu können. Wenn von TCP/IP Seite ein Packet hereinkommt mit einer UID die brickd nicht kennt, dann wird es an alle USB Geräte gebroadcastet. In die andere Richtung funktioniert das ähnlich. Für über TCP/IP eingehende Packets deren Response Expected Flag gesetzt ist merkt sich brickd, dass an diese TCP/IP Verbindung ein Packet mit der gleichen UID und Sequenznummer zurück gehen wird (im Normalfall). Auch hier wird gebroadcastet wenn von USB ein Packet reinkommt und keine TCP/IP Verbindung darauf wartet. Callback sind hier speziell. Sie haben die Sequenznummer 0, die nur für Callback verwendet wird und werden immer gebroadcastet. Wenn ein USB Gerät abgesteckt wird, dann sendet brickd für alle UIDs die bis zu diesem Zeitpunkt für dieses USB Gerät bekannt waren einen Enumerate Callback mit Disconnected Flag. Dass heißt dann aber auch dass der Enumerate Callback mit Disconnected Flag nicht garantiert werden kann. Wenn niemals mit einer UID kommuniziert wurde oder diese keine Callbacks gesendet hat, dann hat brickd sie nie gesehen und weiss nicht, dass diese zu einem USB Gerät gehört. Alle diese Tabellen werden dynamisch aufgebaut und brickd funktioniert auch ohne sie. In dem Fall wird in beide Richtungen gebroadcastet. Es gibt keinen State in brickd der erst aufgebaut werden muss und dann nicht verloren gehen darf, der für die Kommunikation zwischen TCP/IP und USB nötig wäre. Dass sind alles nur Optimierungen. Abgesehen von der UID-zu-USB Gerät Zuordnung die für den Enumerate Callback mit Disconnected Flag genutzt wird. Das geht hier aber auch nicht besser. Im Gegensatz dazu hatte Brick Daemon v1 sich die Routingtabelle für die Stack IDs gemerkt und auch welche TCP/IP Verbindung welche Callbacks erhält. Beides durfte nicht verloren gehen. Alle diesbezüglichen Probleme gibt es nun nicht mehr. Falls dich C nicht abschreckt kannst du den brickd v2 Code auch schon auf github nachlesen.

Der Brick Daemon ist zwingend für die Übersetzung zwischen USB und TCP/IP nötig. Die WIFI Extension und die zukünftige Ethernet Extension brauchen keinen Brick Daemon auf dem PC, da diese direkt TCP/IP sprechen. Den Brick Daemon für Protokoll v1 gibt es nur die Python. Der neue Brick Daemon für Protokoll v2 ist in C geschrieben, damit er weniger Resources brauch und auf kleinen Rechner wie Routern oder dem Raspberry Pi besser läuft. Auf https://github.com/Tinkerforge/brickd gibt es Brick Daemon v2 schon. Ist allerdings noch nicht ganz fertig. Funktioniert im Moment auf Windows, Linux und Mac OS X. Für Linux und Mac liegt unter src/brickv ein Makefile. Für ARM zu crosscompilen habe ich noch nicht getestet. Du kannst das ja mal versuchen und berichten, ob's schon direkt so funktioniert oder welchen Änderungen noch für ARM nötig sind, denn die fertige Version soll auch auf ARM funktionieren.

Brick Viewer 1.1.14 Make Bricklet flashing fail early on verification error Improve message for WIFI power mode changes Verify UID format before writing it to a Bricklet Fix discovering of plugins for Industrial Bricklets on tinkerforge.com Switch button text from state to action for Dual Relay Bricklet plugin Improve monoflop handling for Industrial Bricklets Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.14 Bricklet Flashing bricht jetzt beim ersten Verifikationsfehler ab Hinweise für den WIFI Power Mode verbessert UID Format wird überprüft bevor neue UID auf das Bricklet geschrieben wird Erkennung der Industrial Bricklets Plugins auf tinkerforge.com korrigiert Text auf den Knöpfen des Dual Relay Bricklet Plugins von Zustand auf Aktion geändert Monoflop Behandlung für Industrial Bricklets verbessert Downloads: Windows, Linux, Mac OS X

Ein Callback kann nur eine Konfiguration haben. Dass heißt, der Distance Reached Callback kann entweder für < 100 mm oder > 700 mm konfiguriert werden. Du kannst es natürlich auch so konfigurieren, dass der Callback ausgelöst wird wenn die Distanz zwischen 100 und 700 mm liegt oder außerhalb des 100 und 700 mm Bereichs. Insgesamt kannst du nur eine Bedingung für den einen Callback definieren. unregister_callback gibt es: register_callback(id, NULL)

Richtig, das Problem betrifft hier im speziellen C. Zum Beispiel in Python kann man da eine Closure verwenden um der Callbackfunktion Kontext mitzugeben. In C funktioniert das nicht. Da wir ihm Rahmen von Protokoll 2.0 eh API brechen werden, werden wir auch ein user_data Parameter für die register_callback Funktion hinzufügen.

Es funktioniert jetzt, dass ich ein Brick als WinUSB kompatibel ausgibt und Windows 8 dadurch von sich aus den passenden Treiber installiert. Dadurch kann man dann in kürze Bricks anstecken unter Windows 8 und sie funktionieren ohne weiteres Zutun, wie man das z.B. von USB Sticks kennt

Wie in diesem Thread bereits erwähnt kann Windows 8 selbst den passenden Treiber auswählen, wenn sich das USB Gerät passen als kompatibel ausgibt. Ich habe das jetzt zum Funktionieren gebracht für die Bricks. Dadurch wird in kürze keine extra Treiberinstallation mehr nötig sein auf Windows 8. Man kann einen Brick dann einfach anstecken und er funktioniert, wie man das z.B. von USB Sticks kennt

Richtig, unter Windows 8 kann man standardmässig nur noch signierte Treiber installieren und der Treiber der Brick Daemon beiliegt ist nicht signiert. Der Zadig Treiberinstaller von den libusb Leuten kann aber den passenden Treiber signiert installieren. Nic, ich geben dir recht, dass muss auf der brickd Treiberinstallationsseite erwähnt werden. Das Problem ist hier im Forum schon bekannt, ich bin dann aber irgendwie nicht dazu gekommen es ordentlich zu dokumentieren. In Zukunft (wahrscheinlich im Rahmen von Protokoll 2.0) sollen die brickd und brickv Installer die Treiber die sie mitbringen auch gleich installieren und im Falle von Windows 8 auch die signierte Version. Nachtrag: Dokumentation hat jetzt einen Abschnitt über Windows 8.

Ja, ein Brick im Bootloader und ein geflashter Brick sind für das Betriebssytem zwei verschiedenen Geräte, die auch zwei verschiedene Treiber verwenden. Ein Brick im Bootloader ist eine serielle Schnittstelle (die über ein USB Gerät ins System gekommen ist). Ein geflashter Brick ist ein normales USB Gerät, das ein Custom Protokoll spricht.

Einen Brick flashen und mit dem Brick normal über den Brick Viewer arbeiten sind zwei verschiedenen Dinge, die zufällig im gleichen Programm sind.

Das kann mehrere Ursachen haben: 1) Leuchtet die blaue LED neben der USB Buchse auf dem Servo Brick wenn USB angeschlossen ist? 2) Wird der Brick im Geräte Manager richtig angezeigt? Da sollte kein gelbes Ausrufezeichen oder ähnliches angezeigt werden. Hast du den Treiber aus dem drivers Verzeichnis, dass brickd beiliegt installiert?

mb_convert_encoding wird hier benutzt um den String nach UTF-32LE zu konvertieren. Aus UTF-32LE kann ich dann die eigentlichen Unicode Codepoints ausrechnen. Dabei lasse ich PHP mit der auto option raten/ermitteln in welchem Encoding deine .php Datei und damit der "test äöüß" String ist. Das Problem hier scheint zu sein, dass PHP nicht in der Lage ist das in deinem Fall zu bestimmen. Die Encodings die PHP unterstütz sind hier aufgelistet http://www.php.net/manual/de/mbstring.supported-encodings.php Du kannst jetzt versuchen deine .php Datei mit einem anderen Encoding zu speichern, bzw. auto hier mb_convert_encoding($string, "UTF-32LE", "auto") zum Encoding deiner .php Datei ändern.

Das kann eigentlich kein Softwareproblem sein, daher sollte das mit dem Flashen nichts zu tun haben. Die andere Software war wahrscheinlich SAM-BA von Atmel. Die haben wir zum Flashen verwendet bevor wir das in den Brick Viewer eingebaut haben. Das hört sich eher nach einem Hardwareproblem an. Testest du denn beide Master Bricks an der gleichen Stromversorgung, also gleichen USB Port am Rechner oder gleiches USB Netzteil etc? Nicht dass das Problem die externe Stromversorgung ist.