photron

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?

Gut! Damit haben wir jetzt eine funktionierende und eine nicht funktionierende Version. So können wir jetzt die funktionierende Version Schritt für Schritt abändern bis das Problem auftritt und dann hoffentlich erkennen was das Problem verursacht und es beheben. Hier eine weitere Version in der libusb wieder etwas mehr tut als in der Version davor: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v3.dmg Jetzt die Frage an dich: Tritt das Problem mit dieser Version auf oder nicht?

Du muss die Temperatur auch abfragen, sonst kannst du sie nicht anzeigen. Dir fehlen diese beiden Zeilen vor dem lcd_20x4_write_line Aufruf: int32_t temperature; ptc_get_temperature(&ptc, &temperature); Oder wenn du die Temperatur per Callback auf's LCD schreiben willst dann muss du deine lcd_20x4_write_line Aufruf in die cb_temperature Funktion verschieben. Dazu muss du dann auch das lcd Objekt an die Callback Funktion geben, was du so tun kannst: ptc_register_callback(&ptc, PTC_CALLBACK_TEMPERATURE, (void *)cb_temperature, &lcd); void cb_temperature(int32_t temperature, void *user_data) { LCD20x4 *lcd = user_data; lcd_20x4_write_line(lcd, ... } Dann kannst du lcd_20x4_write_line nicht wie printf verwenden: lcd_20x4_write_line(&lcd, 0, 0, "Temperature: %f °C.\n", temperature/100.0); Das Formatieren des Textes muss du vorher selber machen, z.B. so: char line[21]; // 20 Zeichen + NUL-Terminator snprintf(line, sizeof(line), "Temperature: %.2f \xDFC", temperature/100.0); lcd_20x4_write_line(&lcd, 0, 0, line); Mittels snprintf den String formatieren und ihn dann an lcd_20x4_write_line übergeben. Ich habe hier auch %.2f statt %f verwendet, da %f fix 6 Nachkommastellen verwendet, es reichen aber 2 aus (spart auch Platz). Das .2 drückt aus, dass nur 2 Nachkommastellen ausgegeben werden sollen. Auch funktioniert "°C" nicht, da das Grad Zeichen kein ASCII Zeichen ist und abhängig von deinem Editor verschieden kodiert gespeichert werden kann und keine diese Kodierungen passend für das LCD ist. Das LCD hat seinen eigenen speziellen Zeichensatz und das Gradzeichen steht darin an Position 223 (0xDF). Dies kann man in C/C++ in einem Stringliteral mit "\xDF" hinschreiben.

Da hätte es schon längst genannt sein sollen. Irgendwie muss mir das entgangen sein Jetzt steht's da, danke für den Hinweis.

Okay, das Log sieht leider auch aus wie erwartet. libusb sieht, dass der Adapter (05ac:1402) eingesteckt wird und fragt dann so Informationen ab, wie an welchem Port das Gerät angeschlossen ist und wie das Gerät heißt (seinen Device Descriptor). Das sollte eigentlich gar kein Problem machen. Brickd funktioniert aber an sich, wenn du einen Brick ansteckst, dann taucht der auch in brickv auf? Jetzt müssen wir hier mal die gröberen Mittel anwenden. Hier eine Version in der libusb nichts mehr tut, außer sich von IOKit sagen zu lassen, ob ein USB Gerät ab- oder angesteckt wurde. libusb tut dann aber mit dieser Information nichts. Diese brickd Version ist jetzt an sich nicht mehr funktional, da ich libusb verkrüppelt habe, diese Version ist rein zum testen. http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f_v2.dmg Meine Erwartung ist, dass es jetzt funktioniert und dass das Problem in libusb liegt.

Okay, es geht also kaputt wenn du brickd startest, wenn der Adapter angesteckt ist. Geht es auch kaputt oder funktioniert erst gar nicht wenn du den Adapter ansteckst während brickd schon läuft? Die eigentliche Frage dahinter ist: Macht der Start von brickd es kaputt oder die Anwesenheit von brickd? Statt "sudo kill <pid>" kannst du launchctl benutzen: sudo launchctl stop com.tinkerforge.brickd Und zum Starten: sudo launchctl start com.tinkerforge.brickd Um dem ganzen mal auf den Grund zu gehen hier eine aktuelle Version von brickd. Die libusb Version ist von 1.0.9 auf 1.0.17 aktualisiert und es gibt jetzt eine --libusb-debug Option: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_8_c29031d96a58de32fad68e53ef13283690852b8f.dmg Nach der Installation mittels "sudo launchctl stop com.tinkerforge.brickd" den Launch Daemon für brickd stoppen. Dann den Ethernet Adapter ab- und anstecken damit er wieder funktioniert und jetzt manuell brickd im Terminal starten: sudo /usr/libexec/brickd.app/Contents/MacOS/brickd --debug --libusb-debug Das startet brickd selbst mit Logging auf Debug Level und aktiviert auch die Debug Logausgabe von libusb. Daraus ergibt sich hoffentlich ein Hinweis auf das Problem. Das wird sehr viel an Ausgabe produzieren. Am besten leitest du die Ausgabe in einen Datei um: sudo /usr/libexec/brickd.app/Contents/MacOS/brickd --debug --libusb-debug &> debug.log Dies leitet die Ausgabe in eine Datei namens debug.log im aktuellen Verzeichnis um. Diese Datei hängst du dann einfach an einen Forum-Post an und ich werde dann hoffentlich daraus schlau Vielleicht hilft aber auch das Update von libusb und das Problem tritt mit dieser brickd Version gar nicht mehr auf.