photron

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.

Okay, der USB Ethernet Adapter hat keine PID:VID Überschneidung mit den Bricks, das wäre auch sehr sehr ungewöhnlich gewesen "BSD Name: en2" in der Ausgabe von "system_profiler SPUSBDataType" sieht für mich so aus als hätte OSX den Adapter erkannt und eingebunden, da en2 der Ethernet Interface Name ist, denke ich. Wie genau sieh das den aus wenn der Adapter nicht funktioniert? Was passiert nicht, wenn brickd läuft, im Vergleich zu wenn brickd nicht läuft? Das Log ist sehr unspannend Ist das Problem neu? Im Sinne von: vorher hat der USB Ethernet Adapter schon mal zusammen mit brickd funktioniert? Oder testet du heute diese Kombination das erste Mal?

Das ist ungewöhnlich. Muss nur brickd laufen, um das Problem zu erzeugen, oder muss auch noch ein Brick angeschlossen sein? brickd erkennt Bricks an ihrer USB VendorID:ProductID 16d0:063d. Alle anderen USB Geräte werden ignoriert. Mit folgendem Befehl kannst du im Terminal den USB Bus ansehen: system_profiler SPUSBDataType Dort stehen auch VendorID und ProductID jedes USB Gerätes. Welche hat dein USB-Ethernet-Adapter? Du kannst dir auch ansehen was brickd selbst dazu meint. Unter /var/log/brickd.log liegt eine Logdatei. Du solltest da keine Warnings oder Errors sehen, zu erkennen an <W> und <E>. Es könnten Warnings der Form "Could not cancel pending read transfer" vorhanden sein, diese haben aber nichts mit dem Problem zu tun. Das kann eigentlich nicht das Problem sein, wenn es hilft brickd zu beenden. Denn der Stromverbrauch eines Bricks hängt nicht davon ab, ob brickd läuft oder nicht.

Die Dokumentation listet jetzt bcmath und sockets als benötigte Extensions auf und die nächste Version der PHP Bindings wird prüfen ob bcmath und sockets Extension verfügbar sind und sich ansonsten per Exception beschweren.

Das Problem ist, dass die Sockets Extension standardmäßig nicht aktiviert ist in der Windows-Distribution von PHP, die es auf der PHP Webseite zum herunterladen gibt. Du musst in der php.ini folgende Zeile einfügen: extension=ext/php_sockets.dll Mir war bis eben nicht bekannt, dass die Socket Funktionen eine Extension sind. Daher ist das bisher noch nicht dokumentiert, ich werde das verbessern.

Edor und BuddaKaeks: Falls eure Rechner auch Renesas USB 3.0 Controller verwenden, dann schaut doch auch mal bitte welche Treiberversion da installiert ist. Es muss 2.1.16 oder neuer sein damit es funktioniert.

Kein Problem, das Problem ist gelöst, das ist was zählt Der Geräte Manager zeigt den Brick in diesem Fall immer an. Der Name hängt wie gesagt damit zusammen aus welcher Quelle Windows ihn nimmt, das der sich ändert hat nichts zu bedeuten. als auch mit der speziellen mit der Logausgabe reproduzieren können. Das Problem war also wirklich der zu alte Treiber, mit dem libusb nicht klar kam. Das ist hier speziell ein Problem zwischen libusb und dem Renesas USB 3.0 Treiber vor Treiberversion 2.1.16, der Geräte Manager ist von diesem Problem nicht betroffen. libusb versucht eine Funktion des USB Treiber zu verwenden, um den Verbindungsstatus der USB Geräte zu erfahren. Genau diese Funktion hat aber eine Fehler im alten Renesas Treiber. Dies führt dazu, dass libusb das betroffene USB Gerät nicht auflistet wenn brickd libusb nach der Liste der USB Geräte fragt. Dadurch taucht dann der Brick im Endeffekt nicht in brickv auf. Das sieht alles sehr gut aus, ich kann auch keine weiteren Probleme im Log erkennen.

Okay, hier eine brickd Version bei der libusb Debug Ausgabe aktiviert ist. Dazu zunächst alle anderen brickd Instanzen stoppen und sicherstellen, dass der Master Brick angesteckt ist. Dann diese brickd.exe mit --debug und --log-to-file Option starten: brickd.exe --debug --log-to-file --log-to-file deshalb, weil die Logausgaben umfangreich sein werden. brickd schreibt dann eine brickd.log Datei in den Ordner in dem brickd.exe liegt. Dann einen Moment warten, damit brickd seine Arbeit tun kann, und dann wieder beenden. Jetzt steht hoffentlich im brickd.log was das Problem ist. Daher hätte ich dann gerne die brickd.log Datei. Am einfachten hängst du sie hier an einen Post an. Wir kommen dem Problem schon noch auf die Schliche brickd_libusb_debug.zip

Das ist ein Problem. Laut libusb.org hat der Renesas Treiber vor Version 2.1.16 einen Bug der verhindert, dass libusb damit richtig umgehen kann. Allerdings ist der Link zu einem neueren Treiber veraltet. Wir sollten diesen Hinweis wohl mal ins FAQ aufnehmen. Diese Version sollte das auf libusb.org beschriebene Problem nicht mehr haben. Daher wundert es mich, dass das nicht geholfen hat. Das der Brick ohne Treiber im Geräte Manager als Master Brick, mit Treiber aber als Tinkerforge Brick auftaucht ist normal. Ohne Treiber nimmt Windows den Namen auf dem USB Descriptor des Bricks, da hat jeder Brick seinen Namen stehen. Mit Treiber nimmt Windows den Namen aus dem Treiber. Wir verwenden für alle Bricks den gleichen Treiber, daher haben alle Bricks nach der Treiberinstallation den gleiche Namen. Windows 8 macht das besser, vor allem, da Windows 8 ohne extra Treiber klar kommt. Eigentlich solle Windows den Treiber automatisch beim Einstecken des Bricks finden und einreichten. Extra zu diesem Zweck registrieren der brickd und der brickv Installer den Brick und den Bootloader Treiber beim System, wenn die erkannte Windowsversion diese benötigt. brickd.exe --debug und USBView Screenshot sehen leider wie erwartet aus. Was ist das USB-Verbundgerät am Renesas USB Hub? Kannst du das abstecken? Wenn ja, findet brickd dann den Master Brick? Einen weiteren USB Hub zu verwenden bringt wahrscheinlich nichts, so lange der Renesas USB 3.0 Hub des Laptop mit in der Kette ist. Bzw. ich verstehe dich auch richtig, dass du mit dem extra Hub am Laptop keinen erfolgt hattest, Windows finden den Brick, brickd aber nicht?

ThirtySomething, die libusb die dem brickd 2.0.8 auf Windows beiliegt sollte mit dem Renesas Controller parat kommen. Die Information aus dem Geräte-Manager sehen aus wie erwartet, bzw. bringen mich ertsmal nicht weiter bei dem Problem. Steckt denn der Brick an einem der USB 3.0 Ports, oder steht er an einem der USB 2.0 Ports des Intel Series 6 Chipsatzes? Wobei USB 2.0 eigentlich keine Probleme machen sollte. Welche Treiberversion ist für den Renesas Controller installiert? brickd zum Testen Hier einmal zum Testen brickd 2.0.8 mit aktualisierter libusb: http://download.tinkerforge.com/_stuff/brickd_windows_2_0_8_d5aa1f0b606a70bb41a114aba414cb41682eb35a.exe USB View Tool Und hier ein Tool von Microsoft, das den gesamten USB Bus als Baum darstellt. Ein Screenshot davon mit angestecktem Brick könnte hilreich sein. http://download.tinkerforge.com/_stuff/usbview.exe Ansonsten muss ich mal sehen wie ich aus libusb raus bekomme was das Problem ist. brickd in Debug Modus Was du auch noch mal testen kannst ist den Brick Daemon Dienst über die Computerverwaltung zu stoppen und dann brickd.exe manuell aus dem Explorer heraus starten. Am besten legst du eine Verknüpfung zu brickd.exe an und hängst dann hinten an das Ziel der Verknüpfung " --debug" (ohne die "") an. Dann über die Verknüpfung brickd starten. Ich würde erwarten dass du beim Anstecken des Bricks an USB diese Meldung siehst, die besagt, dass Windows ein neues Gerät gefunden hat: <D> <other|main_windows.c:213> Received device notification (type: arrival) Aber nicht diese, die besagt, dass libusb ein neues USB Gerät gefunden hat welches ein Brick ist: <D> <usb|usb.c:118> Found new USB device (bus: 1, device: 2) Das würde meine Erwartung bestätigen, dass libusb den Brick nicht findet und damit brickd ihn nicht finden kann.