photron

Danke für den Hinweis, ist korrigiert.

Thanks for packaging our software and spreading the word. I did not actually test the packages, but here are some comments from just looking at the AUR webpages: The brickv package has a brickd dependency, but brickv can be used without brickd on the same system and even without brickd at all, if you're connected to a stack with a WIFI or Ethernet Extension. Maybe in archlinux packages can recommend other packages the way Debian packages can? brickd doesn't use libusb-0.1 as provided by the libusb-compat package, but it uses libusb-1.0 as provided by libusbx package. Because libusb-compat itself depends on libusb-1.0 brickd ends up with the correct dependency. You could just cut libusb-compat from the dependency chain and depend on libusb-1.0 directly. The Perl bindings you packaged from CPAN are not the official ones. They were created by a user, are incomplete and outdated by now. The official ones can be found here: http://www.tinkerforge.com/en/doc/Software/API_Bindings_Perl.html They are not on CPAN yet, but will be soon.

reto.koenig danke für die detaillierte Darstellung des Nutzens eines DeviceListeners. Es ist kein Problem eine DeviceListener Interface als Basis aller Device Listener einzubauen. Ich frage mich an der Stelle, ob man nicht einen Schritt weiter geht und einen TinkerforgeListener neben eines DeviceListeners einbaut, der dann als Basis für alle Listener dient, also auch der der IPConnected: Connected, Disconnected und Enumerate. Also so: interface TinkerforgeListener {} // Basis aller Listener interface EnumerateListener extends TinkerforgeListener {} interface DeviceListener extends TinkerforgeListener {} // Basis aller Device Listener interface StateChangedListener extends DeviceListener {} Was haltet ihr davon?

Die Dokumentation sagt jetzt explizit: Windows, Linux, Mac.

Während der Schlafphase läuft das Programm ja auch nicht, da will dann ja auch keiner mit dem Brick reden. Aber nach dem der Mac wieder aufgewacht ist ist die Kommunikation weiterhin unterbrochen. Ich hab mir das jetzt mal genauer angesehen und zumindest unter Linux und Mac ist es so, dass beim Suspend die USB Kommunikation beendet wird und beim Resume neu aufgebaut wird. brickd verwendet aber über den Suspend hinweg den gleichen libusb Handle für den Brick. Allerdings läuft dieser nach dem Resume ins Leere, weil durch den Neuaufbau der USB Kommunikation der Brick jetzt einen neuen/anderen Handle hat. Soweit ich das sehe kann brickd nicht erkennen, ob der Handle zum Brick ins Leere läuft oder nicht. Was brickd aber tun kann, ist auf die Ursache des Problems zu reagieren, den Suspend. Die angehängt brickd Version lauscht jetzt auf den Resume Event von Mac OS X, der besagt, dass der Rechner gerade aus einem Suspend aufgewacht ist. In diesem Fall schließt brickd alle linusb Handles und öffnet sie neu. LinTec, damit sollte dein Problem behoben sein. Kannst du das bestätigen? Für Linux habe ich auch eine Lösung in Arbeit und unter Windows muss ich noch testen ob das Problem dort überhaupt auftritt. brickd_macos_2_0_10_wakeup.dmg

Okay, eine LED wird kein Problem machen. Es gibt unter Linux und Mac das Problem, dass brickd nach einem Suspend nicht mehr mit den Bricks kommunizieren kann. Das kann durch einen Neustart von brickd oder eine Reset der Bricks behoben werden. Das Problem ist, dass brickd das nicht mitbekommt, wenn das passiert. Daher siehst du das auch nicht im Logfile. Ich denke ich weiß wie das Problem zu beheben ist, wenn brickd das Problem erkennen könnte. Daher meine Frage, ob dein Problem mit einem Suspend zusammenfällt. Wenn ja, dann ist es wahrscheinlich das oben genannt Problem und ich kann dir leider momentan keine wirkliche Lösung anbieten. Standardmäßig wird das Debug Loglevel nicht ausgegeben, da dies sehr detailliert Auskunft über die stattfindende Kommunikation gibt. Was dazu führen kann, dass brickd bei der Abarbeitung der Kommunikation durch die Logausgabe selbst merklich gebremst wird. Du kannst das Loglevel in /etc/brickd.conf einstellen und muss dann brickd neustarten, um die Änderungen zu übernehmen. Wobei dies wahrscheinlich keine weiteren Erkenntnisse bringen wird, da Fehler oder unerwartete Dinge auf Error und Warn Loglevel gemeldet werden und diese beiden standardmäßig ausgegeben werden.

Hast du am Quad Relay eine Last angeschlossen oder schaltet das einfach so vor sich hin? Ich nehme mal an das Problem ist jetzt schon mehrfach aufgetreten. Passiert das immer nach ca. 2 Stunden? Bzw. fällt das mit einem anderen Ereignis zusammen? Leg sich der Mac vielleicht genau dann schlafen wenn das passiert? Teste mal bitte ob es auch hilft brickd neuzustarten, statt USB ab und an zu stecken, wenn das Problem auftritt. Dazu in einem Terminal folgende Befehle ausführen: sudo launchctl stop com.tinkerforge.brickd sudo launchctl start com.tinkerforge.brickd

Sprachen die spezifisch für ein Betriebssystem oder eine Hardware Architektur kompiliert werden, müssen natürlich passend für das RED Brick kompiliert werden, bzw. können dann auf dem RED Brick kompiliert werden. Das wären z.B. C/C++ oder Delphi. Java und auch C# verwenden aber Bytecode der nicht spezifisch für ein Betriebssystem oder eine Architektur ist. Das der C# Compiler .dll und .exe Dateien erzeugt heißt nicht, dass diese spezifisch für Windows wären. Eine unter Windows erstelle C# .exe Datei läuft unverändert unter Linux mit Mono.

Vielleicht sind im Bricklet A am Master Brick zwei Pins krumm? Genau die die für Pin 2 und 3 des Bricklets zuständig sind?

Okay, laut lsusb ist der Brick da. Allerdings bekommt brickd Fehler bei der Interaktion mit dem Brick. Bevor brickd irgendetwas mit dem Brick tut resettet es die USB Kommunikation. Das schlägt fehl: 2014-01-25 17:24:26.523655 <E> <usb|usb_stack.c:278> Could not reset USB device (bus: 2, device: 4): LIBUSB_ERROR_NOT_FOUND (-5) Bei einem späten Versuch scheint der Reset zu funktionieren, aber das Auslesen des USB Config Descriptors schlägt fehl. 2014-01-26 12:46:49.676619 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 4): LIBUSB_ERROR_TIMEOUT (-7) Das ist komisch, ist mir beides noch nicht untergekommen. Ich habe gerade auch noch mal Mint 16 32bit in einer VirtualBox VM getestet und keine Probleme mit durchgereichten Bricks. Ich habe gerade kein VMware zur Hand zum Testen. Wie dem auch sei, hier mal eine brickd Version die keinen initialen Reset durchführt. brickd-2.0.10-d1_amd64.deb brickd-2.0.10-d1_i386.deb

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen. Ich meinte, ob zur Laufzeit dem Linux-System über Rechtevergabe an den BrickV der direkte Zugriff an ein bestimmtes USB-Device erlaubt wird. Nein, brickv braucht keine root Rechte. Das läuft anders. Typischerweise hat nur root Zugriff auf die USB Geräte. Daher läuft brickd als root und kann daher auf die USB Geräte zugreifen. brickv kann sich dann zu brickd verbinden und mit den Bricks kommunizieren ohne selbst root Rechte zu brauchen. Sprich, du hast da keine Rechteproblem mit brickv. Ich hoffe Du meinst das Download-Paket von TF, dann ja, es mussten aber noch einige Dependencies für den BrickV via Internet während der Install. nachgeladen werden. Mit den Linux eigenen Begrifflichkeiten bin ich nicht bewandert, ich bin schon froh, dass ich soweit gekommen bin Ja, dass meinte ich. Unser .deb Packet von der Downloadseite installiert brickd und richtet ihn als Service ein, damit er automatisch im Hintergrund mit root Rechten läuft. Ja. Ja, also zumindest über die Toolbar-Leiste des VMWare Players, rechts oben. Dort werden alle relevante HW des Host eingeblendet und lassen sich connecten. Okay, dann ist der Brick nach VMwares Meinung wohl durchgereicht. Dann ist jetzt der nächste Schritt sich anzusehen wie Linux das sieht. Dazu einen Terminal in der VM öffnen und lsusb eingeben und Enter drücken. Das sollte sowas in der Art hier ausgeben: Bus 006 Device 030: ID 16d0:063d GrauTec Bus 006 Device 029: ID 16d0:063d GrauTec Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 045e:078c Microsoft Corp. Bus 004 Device 004: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [b110 Optical USB Mouse] Bus 003 Device 006: ID 16d0:063d GrauTec Die ersten beiden Zeilen sind Bricks, zu erkennen an 16d0:063d. Ob da bei dir dann GrauTec oder MCS steht hängt davon ab wie aktuell, die usb.ids Datei des Linux ist. Wenn bei durchgereichtem Brick lsusb keine Zeile mit 16d0:063d ausgibt, dann erkennt Linux den Brick nicht.

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen. Dass heißt, du hast dabei auch folgende Reihenfolge getestet: VM starten, Brick durchreichen, brickv starten und Connect klicken? Sagt dir das VMware oder hast du das mit lsubs in der VM nachgesehen?

industrial_quad_relay_get_monoflop() erwartet Pointer auf Variablen in die es dann die drei Werte schreiben kann. Hier ein Beispiel für Pin 0: uint16_t value; uint32_t time uint32_t time_remaining; industrial_quad_relay_get_monoflop(&iqr, 0, &value, &time, &time_remaining); printf("value %u, time %u, time_remaining %u\n", value, time, time_remaining);

Hast du den Brick in die VM durchgereicht bevor oder nachdem du in brickv in der VM auf Connect geklickt hast? Falls du den Brick danach durchgereicht hast, dann muss du einmal in brickv Disconnect und dann wieder Connect klicken, um ein Enumerate auszulösen. Wenn du den Brick per USB ansteckst sendet er von sich aus ein Enumerate. Wenn du ihn aber durchreichst ist das zwar für die VM das anstecken eines neuen USB Gerätes, aber nicht für den Brick. Daher hat bei dieser Abfolge brickv den Brick einfach noch nicht gesehen. Falls es dass nicht ist, kann du dir verschiedene Dinge ansehen (alles in einem Terminal): Das brickd Log: less /var/log/brickd.log Möglicherweise ist hier ein Hinweis auf das Problem zu finden. Als nächstes die Liste der USB Geräte: lsusb Hier tauchen Bricks unter der ID 16d0:063d auf. Abhängig davon wie neu deine usb.ids Liste ist wird GrauTech oder MCS als Vendor angegeben. Wenn hier kein solcher Eintrag vorhanden ist, dann hat der Kernel den Brick nicht erkannt. Dann ist da noch das Kernel Log: dmesg Hier solltest du im Normalfall beim Durchreichen am Ende des Logs Meldungen wie diese sehen: [204458.156050] usb 6-3: new full-speed USB device number 28 using ohci_hcd Oder aber Fehlermeldungen des Kernels die dann auch mit "usb" beginnen.

Wie Loetkolben schon richtig sagt kann das EEPROM vom Brick aus beschrieben werden. Der Brick Viewer hat einen Dialog dafür. Da kannst du den Brick, den Bricklet Port an dem dein Bricklet angeschlossen ist und die passende Firmware auswählen und der Brick Viewer schreibt diese dann über den Brick in das EEPROM des Bricklets. Keine zusätzliche Hardware nötig.

Eigentlich wäre es besser gewesen, wenn du einen neuen Thread erstellt hättest, aber nicht so wichtig Zu deiner Frage: Du möchtest also dein eigenes IO-16 Bricklet bauen. Wenn du von ICs sprichst meinst du M24C64 (EEPROM), MCP23017 (I/O Expander) und PCA9306 (I2C Voltage-Level Translator), nehme ich mal an. Wenn du das IO-16 Bricklet nach unserem Schaltplan nachbaust wird jeder Brick es erkennen, wenn es geflasht ist. Du kannst natürlich ein exaktes IO-16 Bricklet nachbauen, aber du musst nicht. Der Knackpunkt ist, dass das EEPROM die I2C Adresse hat, die der Brick erwartet. Das wird aber einfach dadurch sichergestellt, dass du das gleiche EEPROM wie wir verwendest und es auch gleich anschließt. Den Rest der Hardware des Bricklets kannst du ändern, solange du dich an die elektrische Spezifikation des Bricklet-Steckers hältst. Dann musst du aber natürlich auch eine passende Firmware für dein Bricklet schreiben. Die Erkennung läuft so ab: Beim Start versucht der Brick das EEPROM des Bricklets über I2C auszulesen. Die I2C Adresse des EEPROMs ist in unserem System für alle Bricklets gleich, daher können wir sie im Brick fest vorgeben. Wenn der Brick die Firmware des Bricklets erfolgreich vom EEPROM in seinen Flash übertragen hat führt er diese aus, um so deren Funktionalität dem Nutzer zur Verfügung zu stellen. Sprich, wenn deine Hardware die elektrische Schnittstelle eines Bricklets hat und auf dem EEPROM eine Firmware gespeichert ist, die die Software-Schnittstelle eines Bricklets erfüllt, dann wird deine Hardware vom Brick als Bricklet erkennt und auch funktionieren.

Die Beispiele für Callbacks in PHP sehen vernünftig aus, warum wird hier aber trotzdem davon abgeraten ? Wenn das mit Callbacks schlechter funktioniert als "teueres" Polling mit Getter-Funktionen, dann sollte ein Hinweis in die Doku rein "vom Benutzen der Callbacks in PHP ist abzuraten, weil... usw" oder bitte von den PHP Experten genauere Erklärungen, ansonsten wirkt das u.U. hier für Unsicherheiten. Ganz grundsätzlich: Callbacks funktionieren in PHP genauso gut oder schlecht wie in anderen Bindings. Es gibt hier kein Problem oder Nachteil mit Callbacks in PHP! Der Punkt auf den AuronX abzielt und den ich versucht habe darzustellen ist ein anderer: Callbacks sind gut dafür Wertänderungen/Ereignisse mitzubekommen ohne ständig einen Getter dafür aufrufen zu müssen. Das ist vor allem in Programmen nützlich die länger laufen. Genau dies ist aber bei PHP in seiner ursprünglichen Verwendung zur Erzeugung von Websites nicht der Fall. Darauf zielte der Teil ab in dem ich Callbacks für PHP als Website-Generator als eher nicht nützlich erachte. Dies war und ist keine Aussage über Callbacks in PHP in Allgemeinen, sondern nur für diesen speziellen Fall. Die Aussage, dass ich Callbacks für Website-erzeugende Programme nicht als nützlich erachte hängt nicht mit PHP zusammen sondern gilt auch für alle anderen Bindings. Das eigentliche Problem mit Callbacks in PHP ist, dass ich mich als Nutzer der Bindings darum kümmern muss sie zu erhalten. Bei anderen Bindings passiert das automatisch, was Vorteile und auch Nachteile hat. Wenn ich in PHP Callbacks verwenden will muss ich irgendwo in meinem Programm an geeigneter Stelle und zu geeigneter Zeit dispatchCallbacks() aufrufen. Am einfachsten ist dass, wenn man es so macht wie alle PHP Beispiele die Callbacks verwenden. Sie konfigurieren als erstes alles was sie brauchen und rufen dann dispatchCallbacks(-1) auf. Mit -1 aufgerufen bedeutet das: "kümmer dich für immer um eingehende Callbacks und returne niemals". Dieses Muster funktioniert gut, ich muss aber mein Programm darauf hin ausrichten, dass es für immer in dispatchCallbacks(-1) stehen wird und ich dann in den Callbacks arbeiten muss. Wenn ich mein Programm nicht darauf ausrichten kann, aber dennoch Callbacks verwende will, dann muss ich mir Gedanken machen darüber wann und wie ich dispatchCallbacks() aufrufe, um es mit meinem restlichen Programm zu kombinieren. Das kann im Einzelfall kompliziert werden. Daher meine Aussage darüber, dass man sein PHP Programm entweder auf die Verwendung von Callbacks ausrichten sollte, oder wenn das nicht möglich ist, besser keine Callbacks verwenden sollte. Das ist als guter Rat bzw. Best-Practice-Hinweis zu sehen. Ich rate damit niemanden von Callbacks im generellen ab, ich weise aber darauf hin, dass die Verwendung von Callbacks in PHP schwieriger sein kann (aber nicht muss) als mit anderen Bindings.

Nein, das ist nicht nötig. Es funktionier in beiden Weisen. Die IPConnection muss nicht verbunden sein um Device Objecte zu erzeugen.

Das würde ich jetzt nicht so negativ darstellen. Das Problem mit PHP und Callbacks ist, dass PHP (zumindest zum Zeitpunkt der Entwicklung der Bindings) keine Threads kannte. Daher muss das PHP Programm selbst für die Abarbeitung der Callbacks sorgen, indem es die dispatchCallbacks() Methode der IPConnection aufruft. Ob die Verwendung von Callbacks sinnvoll ist hängt natürlich auch davon ab was dein PHP Programm tut. Wenn es eine Webseite erstellt dann sind Callbacks nicht sehr sinnvoll und man fährt besser mit Gettern. Wenn ich aber auf ein Ereignis wie den Druck einen Knopfes am Dual Button Bricklet warten will dann sind Callbacks schon sinnvoll. Dennoch ist die richtige Verwendung von dispatchCallbacks() nicht ganz leicht in größeren Programmen. Was dazu führt, dass man sein Programm am besten entweder vollständig auf Callbacks ausrichtet, oder sie gar nicht benutzt. Mittlerweile kann PHP PThreads nutzen und man könnte Callbacks in PHP wie in den anderen Bindings auch durch einen extra Thread ausliefern lassen. Was jetzt aber bitte nicht als "Es gibt bald PHP Bindings mit Threads" verstanden werden soll . Aber zumindest auf der TODO List steht es sich darüber noch mal Gedanken zu machen. Genau so ist das gedacht. Hast du mit diesem Programm Probleme? Die IPConnection stellt die Verbindung zu einem brickd her, über diese Verbindung kannst du dann alle Bricks und Bricklets erreichen die diesem brickd bekannt sind. Wenn es sich um brickd auf deinem PC handelt, dann sind dass alle Stacks die per USB angeschlossen sind. Wenn du die IPConnection zu einem Stack mit WIFI oder Ethernet Extension verbunden hast, dann kannst du alle Bricks und Bricklets diese Stacks darüber erreichen. Denn auf dem Stack mit WIFI oder Ethernet Extension läuft auch eine Art brickd, der sich um das Verteilen der Nachrichten kümmert. Du brauchst also im Normalfall nur eine IPConnection und kannst diese dann für mehrere Devices verwenden.

Die Varistoren sind nicht geklebt, die halten beim Bestücken durch Gravitation.

gcc -pthread -o Temperaturanzeige.c ip_connection.c bricklet_temperature.c bricklet_ptc.c bricklet_lcd_20x4.c Mit "-o Temperaturanzeige.c" sagst du gcc er soll das Programm nach Temperaturanzeige.c schreiben, statt Temperaturanzeige.c auch mitzukompilieren. Daher auch das "undefined reference to `main'", weil Temperaturanzeige.c nicht mitkompiliert wurde findet gcc keine main() Funktion und beschwert sich. So sollte das funktionieren: gcc -pthread -o Temperaturanzeige Temperaturanzeige.c ip_connection.c bricklet_temperature.c bricklet_ptc.c bricklet_lcd_20x4.c Jetzt wird Temperaturanzeige.c mitkompiliert und das kompilierte Programm in die Datei Temperaturanzeige geschrieben.

Das hört sich an, als ob das Motion Detektor Bricklet nicht mehr richtig geflashed ist. Um das zu beheben musst du das Bricklet neu flashen. Da der Brick aber in diesem Zustand nicht richtig startet muss du das Bricklet hotpluggen, entgegen dem üblichen Vorgaben. Also erst den Brick per USB anschließen und dann erst das Bricklet an den schon laufenden Brick anschließen und über brickv neu flashen. Siehe http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricklets-wird-im-brick-viewer-nicht-angezeigt -> Defektes Plugin

Nein, die Bricks sind selbst USB Geräte und können nicht als USB Host agieren, um andere USB Geräte daran anschließen zu können. Sprich ein Master Brick mit WIFI Extension kann nicht als Brücke zwischen WLAN und einem weiteren USB Gerät genutzt werden.

Da springen mir direkt keine richtig groben Fehler ins Auge. Was mir aber auffällt ist diese Zeile strecke = (zaehler - zwSpeicher1) * (radUmfang / 1000); Wobei zaehler, zwSpeicher1 und radUmfang Integerwerte sind. Dies führt dazu, dass radUmfang / 1000 == 2 ist und nicht 2.184 (bei radUmfang == 2184). Das verfälscht deine Werte etwas. Dann ist da noch das Busy Waiting: while(waitingStartTime + 1000 > System.currentTimeMillis()){} Da könnte man stattdessen Thread.sleep(1000) nehmen. Aber das hat denke ich nichts mit deinem Problem zu tun, außer das Busy Waiting wäre recht ungenau und führt nicht zu 1 Sekunde Wartezeit, was sich auch wieder auf die Genauigkeit deiner Berechnung auswirkt. Ansonsten schlage ich vor, dass du dein Programm und deinen Aufbau auf ein Minimum reduzierst. Also nur Master Brick und Industrial Digital In 4 Bricklet und in deinem Programm nur noch den Flankenzähler abfragst und den Wert umrechnest. Wenn das funktioniert liegt das Problem im entfernten Teil des Aufbaus. Wenn das nicht funktioniert, muss man sich nur noch den minimalen Aufbau genauer ansehen.

Per Bindings fertig Blogeintrag