photron

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?

Zeilenenden sollten kein Problem sein. Was ein Problem sein kann ist, wenn die Sample Point Datei mit dem Internet Explorer heruntergeladen wurde. IE ist so frei und ändert den Inhalt der Datei im dem er einen UTF-8 Byte Order Marker vorne davor hängt. Hier jetzt eine Version von brickv mit robusterem Parsing der Datei, das auch mit dem UTF-8 BOM umgehen kann. http://download.tinkerforge.com/_stuff/brickv_windows_2_0_7_distir4.exe Dann noch eine kleines Programm zum Auslesen der Kalibrierung eines Distance IR Bricklets. http://download.tinkerforge.com/_stuff/distance_ir_get_sample_points.exe Einfach das Programm starten, UID des Bricklets eingeben und Enter drücken. Die Ausgabe sollte für den 150cm Sensor so aussehen, wobei ich aber davon ausgehen, dass sie bei dir anders aussieht und genau dass das Problem ist. 0: 15000 1: 15000 2: 15000 3: 15000 4: 15000 5: 15000 6: 15000 7: 15000 8: 15000 9: 15000 10: 15000 11: 15000 12: 15000 13: 15000 14: 15000 15: 15000 16: 15000 17: 14286 18: 13498 19: 12814 20: 12153 21: 11436 22: 10846 23: 10454 24: 9960 25: 9344 26: 9048 27: 8744 28: 8369 29: 8019 30: 7762 31: 7544 32: 7286 33: 7016 34: 6792 35: 6608 36: 6435 37: 6259 38: 6089 39: 5935 40: 5799 41: 5672 42: 5545 43: 5411 44: 5270 45: 5131 46: 5000 47: 4883 48: 4778 49: 4682 50: 4590 51: 4500 52: 4408 53: 4316 54: 4224 55: 4135 56: 4050 57: 3971 58: 3898 59: 3830 60: 3767 61: 3707 62: 3649 63: 3592 64: 3536 65: 3478 66: 3419 67: 3359 68: 3299 69: 3238 70: 3178 71: 3118 72: 3059 73: 3002 74: 2946 75: 2892 76: 2840 77: 2789 78: 2739 79: 2689 80: 2640 81: 2592 82: 2543 83: 2494 84: 2444 85: 2395 86: 2344 87: 2293 88: 2241 89: 2189 90: 2136 91: 2081 92: 2026 93: 1970 94: 1913 95: 1855 96: 1796 97: 1737 98: 1677 99: 1617 100: 1500 101: 1500 102: 1500 103: 1500 104: 1500 105: 1500 106: 1500 107: 1500 108: 1500 109: 1500 110: 1500 111: 1500 112: 1500 113: 1500 114: 1500 115: 1500 116: 1500 117: 1500 118: 1500 119: 1500 120: 1500 121: 1500 122: 1500 123: 1500 124: 1500 125: 1500 126: 1500 127: 1500

Bist du sicher, dass das Log zu v5 ist? Die "finding cached device for sessionID 0x0168b20cf27e9dd" Zeile kann v5 nicht ausgeben. Das Log kann nur von v4 stammen. Kannst du das nochmal überprüfen ob jetzt erst v5 funktioniert oder schon v4 okay war?

Okay, unter 20cm misst der Sensor nicht mehr richtig, da kommen dann falsche Werte raus, das ist okay. Die Distanz in cm ist also entweder 15cm oder 150cm, ohne Zwischenwerte. Der Analogwert verhält sich aber umgekehrt wie die real angelegte Distanz. Wenn dem so ist, dann ist der Sensor an sich okay, aber die Umrechnung im Bricklet passt nicht. Wenn du dir 2Y0A02.txt ansieht, dann steht da die verwendete Umrechnung zwischen Analogwert und Distanz 3230 entspricht 15cm und 518 entspricht 150cm. Da brickv momentan den Analogwert geteilt durch 100 anzeigt siehst du Werte zwischen 5 und 32. Das kommt also hin. Ich nehme mal an, dass du einen Analogwert von etwa 10 (eigentlich 1058) angezeigt bekommst wenn du dem Sensor eine reale Distanz von 70cm vorhältst. Wenn dem so ist und die anzeigten Analogwerte denen in 2Y0A02.txt entsprechen, dann ist der Sensor okay. Warum nun die Umrechnung nicht passt ist nicht ganz klar. Du kannst testen das Plugin des Bricklets neu zu flashen und dann noch mal die Kalibrierung zu laden.

Okay, und hier die nächste Version. Wie ist's mit der? http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v5.dmg Hier wird jetzt nur noch die SessionID des USB Geräts abgefragt. Wenn das jetzt auch nicht geht bin ich etwas ratlos

Die Anzeige des Analogwertes ist in der Tat in brickv falsch. Das ist ein reines Darstellungsproblem und wird in der nächsten Version behoben sein. Dank für den Hinweise. Die Bricklets werden von uns schon passen für den angesteckten Sensor kalibriert ausgeliefert. Neukalibierien ist nur notwenig, wenn du den Sensor gegen einen anderen Typ tauscht. Es kann aber nicht schaden die Kalibrierung neuzuladen. Das kann dein Problem nicht verursacht haben haben. Unter welchen Bedingungen wird denn 150cm und unter welchen Bedingungen 15cm angezeigt? Schau dir auch einmal die Pins der Brickletstecker am Brick und am Bricklet an, um sicher zu sein, dass dort keiner der Pins krumm ist und einen Kurzschluss verursacht.

Okay, und hier die nächste Version. Wie ist's mit der? http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v4.dmg

Wenn das robuste Beispiel funktioniert, dann sollte kein generelles Problem vorliegt. Der Unterschied zwischen dem robusten Beispiel Beispiel und dem LCD 20x4 Callback Beispiel ist, dass das robuste Beispiel die Bricklets per Enumerate findet und beim Callback Beispiel muss die UID angegeben werden. Wenn du beim Callback Beispiel die falsche UID angibst, dann tritt genau dass auf was du beschreibst. Da du aber sagst, dass nicht-Callback Dinge funktionieren ist das komisch. Dass heißt, das LCD 20x4 Hello World funktioniert (macht Backlight an und schreibt Hello World) mit der UID, mit der dass Callback Beispiel nicht funktioniert?