photron

Wenn dein Barometer Bricklet noch im Brick Viewer auftaucht, dann sind SDA und SCL zwischen Stecker und EEPROM noch intakt. Wenn du 10mbar als Luftdruck angezeigt wird dann kann es an einer defekten I2C Leitung liegen, muss aber nicht unbedingt. Falls du ein Multi-Meter oder einen anderen Durchgangsprüfer zur Hand hast dann kannst du messen ob der I2C Bus noch intakt ist. Ich habe auf dem angehängten Bild aufgemalt wie die I2C Pins des Barometer ICs (weißer Chip) und des EEPROMs (schwarzer Chip) mit dem Stecker verbunden sein müssen, damit es funktioniert. Bei thunderbirds Barometern war jeweils die SDA Leitung zwischen Barometer IC und EEPROM unterbrochen. Wie verwendet du das Bricklet denn? Hast du das wie thunderbird auch draußen im Einsatz, wo es größeren Temperaturschwankungen ausgesetzt ist?

AFAIK you can power the Raspberry Pi via the 5V pins in its extension header. So this would allow this Step-Down Power Supply Shield to power the Raspberry Pi. This would allow to get rid of the cable from the Step-Down Power Supply to the Raspberry Pi. Do you suggest to have an USB hub on this Step-Down Power Supply Shield? One problem with this is that the extension header of the Raspberry Pi does not include USB pins. So you would need an USB cable between the shield and the Raspberry Pi and another USB cable between the shield and the Brick that is stacked on top of the shield, because there are no USB pins in the stack connectors. For just one Brick this doesn't make much sense. You could just connect it directly via USB and power it with this Step-Down Power Supply Shield. To inject 5V from the Step-Down Power Supply Shield into an USB host connector to power a Brick via USB, this would require an USB device connector on the Step-Down Power Supply Shield to connect it to the Raspberry Pi's USB port. If you want to run more than one Brick from this you need extra logic and will end up with a crossbreed of a Step-Down Power Supply and an active USB hub that happens to be powered by the Step-Down Power Supply.

Die SSID ist der Name des WLAN Netzes zu dem sich die WIFI Extension verbinden soll. Der Name unter dem die WIFI Extension dann zu erreichen ist ist der Hostname.

Rufst du auf dem gleichen io4 Objekt mehrfach addInterruptListener() auf? Dann fügst du beim jedem Durchlauf einen weiteren Listener hinzu und dann werden auch mehrere Listener ausgeführt. Wenn das nicht deine Absicht ist, dann solltest du addInterruptListener() nur einmal am Anfang aufrufen. removeInterruptListener(null) ergibt keinen Sinn. Wenn dann musst du dir eine Referenz zum Listner Objekt zwischen speichern: BrickletIO4.InterruptListener listener = new BrickletIO4.InterruptListener() { ... } io4.addInterruptListener(listener); ... io4.removeInterruptListener(listener);

Doch, hier http://www.tinkerforge.com/de/doc/Software/IPConnection_Shell.html#tinkerforge dispatch Wobei auf den Seiten der Bricks und Bricklets ein Link darauf fehlt. Ich werde gleich einen einfügen.

Dann musst du wahrscheinlich einfach nur wieder in den Sicherheitseinstellungen Software aus unbekannten Quellen zulassen, wie in der brickd Installationsanleitung beschrieben. Das wird aber auch in kürze ein Ende haben. Die nächste brickd Version wird höchstwahrschnlich signiert sein und dann hört Mac OS X auf zu meckern.

Die Parameter sind teils positionsabhängig: tinkerforge dispatch --duarion 0 io4-bricklet $io_uid interrupt ...

Funktioniert hier auf Mac OS X 10.8. Hast du vielleicht in der Zwischenzeit auf 10.9 aktualisiert, oder der Gate Keeper ist aus anderen Gründen wieder aktiviert?

Diese Aussage ist alt und nun falsch. Seit Protokoll 2.0 werden Packages mit unbekannter Function ID werden ignoriert, bzw wenn dass Response Expected Flag gesetzt ist, dann wir auch eine Response mit Error Code 2 (FUNCTION_NOT_SUPPORTED) zurück gesendet.

Du muss dafür die valueMask im Listener prüfen. Bei einer steigenden Flanke ist das Bit für den entsprechenden Pin in valueMask gesetzt, bei einer fallenden Flanke nicht.

Hier RC1 für brickd 2.0.9 zum testen: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_9_rc1.dmg

Du kannst natürlich mehrere dispatch Aufrufe per --execute verketten. Ein dispatch Aufruf kann aber jeweils nur auf einen Callback warten. Die Shell Bindings sind in diesem Bezug nicht so mächtig wie die anderen Bindings.

Der dispatch Befehle wartet standardmäßig unendlich lange auf eingehende Callbacks. Die --duration Option kann genutzt werden um das zu ändern. Bei --duration 0 beenden sich der Befehle nach dem ersten behandelten Callback. Bei Werten > 0 wird der Wert als Zeit in Millisekunden interpretiert und für diese Zeit eingehende Callbacks behandelt. Weil --execute nicht in der gleichen Shell ausgeführt wird wie dein Script. Du kann also das Script so nicht aus --execute heraus beenden. Der interrupt callback hat zwei Paramter (interrupt-mask und value-mask) anhand derer du bestimmen kannst welche Pins den Interrupt ausgelöst haben und ob es sich um eine steigende oder fallende Flanke handelt.

Das Problem liegt daran, dass sich libusb an die Dokumentation von Apple hält, statt an Apples Beispielprogramme. Die Zeile um dies es geht ist diese hier: https://github.com/libusbx/libusbx/blob/master/libusb/os/darwin_usb.c#L626 Laut dem Kommentar zu dieser Zeile besagt die Apple Dokumentation, dass ein USB Gerät zuerst geöffnet werden muss, bevor man gewisse Informationen abfragen kann. Ein Beispielprogramm von Apple tut dies aber nicht. Die libusb Entwickler wollten aber auf der sicheren Seite sein und halten sich an die Dokumentation. Der Aufruf von USBDeviceOpenSeize ist aber genau der der deinen USB-Ethernet-Adapter aus dem Tritt bringt. Daher habe ich jetzt eingebaut, dass USBDeviceOpenSeize nur noch für nicht-Apple Geräte aufgerufen wird. Dadurch sollte diese Problem behoben sein und brickd weiterhin normal funktionieren.

Die Callbacks werden von einem Thread der IPConnection aufgerufen. Du darfst aber mit dem GUI nur direkt aus dem Haupt-Thread deines Programms heraus interagieren, sprich was du da tust ist nicht erlaubt. Dass das Programm zufällig in der KiUserCallbackDispatcher Funktion von Windows steht würde ich ehr als zufällig betrachten. Diese Funktion ist eine Funktion des Windows Kernels, sie hat nichts direkt mit den Delphi Bindings zu tun. Um das Problem zu lösen musst du die Interaktion mit dem GUI in den Haupt-Thread verschieben, dazu kannst du z.B. TThread.Synchronize verwenden.

Okay, ich denke wir haben es gefunden v12 sollte das Problem nicht haben und auch wieder normal funktionieren. Die vorherigen Testversionen waren so beschnitten, dass brickd nicht richtig funktionieren konnte.

Okay, damit hat sich mein erster Verdacht nicht bestätigt, also weiter Hier vier neue Versionen zum testen: v8, v9, v10, v11 Ich denke wir sind nah dran.

Bei WEP muss das Passwort die richtige Länge und Form haben. Am besten lässt du dir eins auf der Webseite generieren, die in der Anleitung verlinkt ist. Dann musst du noch darauf achten in welcher Form du das Passwort angeben muss. Bei der WIFI Extension definitiv in hexadezimaler Form und z.B. bei Android auch in hexadezimaler Form. Es kann sein, dass du das bei dir (je nach dem was dein Client ist) in ASCII form angeben musst. AuronX, Im Access Point und Ad Hoc Modus kann die WIFI Extension nur WEP. Nur im Client Modus kann sie auch WPA(2).

Wie hast du denn die WIFI Extension genau eingestellt? Ich habe der Dokumentation mal eine Beispielkonfiguration hinzugefügt (englische Version folgt später). Dann bleibt noch als Frage: Wo taucht die WIFI Extension nicht als Access Point auf?

Hier ist sie. dual-button-bricklet.bin

Meine Annahme war, dass die LEDs nach dem Start aus sind. Ich hätte in den Code schauen sollen. In der Tat werden die LEDs beim Start eingeschaltet. Ich gebe dir Recht, initial aus ist nahe liegender, so ist es jetzt auch abgeändert.

Richtiger Hinweis, ist vermerkt Die Taster sind bedrahtete Bauteile, du kannst also an deren Pins was anlöten. Das wird nicht passieren, dafür sind die beiden zu verschieden. Im Endeffekt würde ein Zusammenlegen höchstwahrscheinlich mehr Arbeit machen als es sparen könnte. Die LEDs sind nach dem Reset aus. Nach dem Reset sind alle Pins im Input Pull-Up Modus. Input heißt, dass sie nicht aktiv getrieben werden (das wäre Output). Pull-Up heißt, dass sie über einen internen (Pull-Up) Widerstand gegen VCC geschaltet sind. Dadurch sind die LEDs initial aus, weil sie an beiden Enden an VCC hängen.

Okay, danke für's Testen. Wir kommen der Sache näher, ich habe eine Vermutung wo das Problem steckt. Ich erwarte, dass v6 funktioniert: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v6.dmg und v7 nicht funktioniert: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v7.dmg PS: Ich hab den v5 Link korrigiert.

0x23 0x20 ist "# ", das ist okay. UTF-8 BOM ist 0xEF 0xBB 0xBF. Ich habs gerade noch mal geprüft und die Datei liegt ohne BOM auf github.com und mit Chrome unter Linux kann ich sie auch so runterladen. Mit Firefox machts auch keine Probleme. Wie dem auch sei, Hauptsache es funktioniert jetzt Die Verbesserungen werden dann auch Teil der nächsten brickv Version sein.

"Alle Versionen" heißt was genau? Alle die ich hier gepostet habe? Im speziellen auch die erste aus diesem Post, in der ich libusb von 1.0.9 auf 1.0.17 aktualisiert habe? Oder auch die offizielle Version 2.0.8 von der normalen Downloadseite?