duaw Posted June 4, 2019 at 10:50 AM Posted June 4, 2019 at 10:50 AM Hallo! Ich habe zwei Fragen zum "stabilen Ansatz". Mein Aufbau: Ich will das (erste und bei mir auch einzige) Bricklet einer Art (hier: RotaryPoti) via USB/localhost erkennen und dieses auch über USB-ab/an-Zyklen betreiben. (macOS, sehe gerade, dass ich mit den Bindings erst bei 2.1.24 bin, sonst aktuell) Wenn das Programm bei bei verbundenem Bricklet, startet, dann ist alles ok: ->cb_enumerate y6V available, NOW valid, callback set Ist verfügbar, ich kann abfragen. Mein callback wird nicht aufgerufen, hat sich ja auch nicht verändert. Dann ziehe ich das USB-Kabel. Frage 1: Beim IPCON_ENUMERATION_TYPE_DISCONNECTED wird dem Callback zwar die uid des nicht mehr vorhandenen RotaryPoti übergeben, aber nicht der device_identifier, der immer 0 ist. Warum? Ausgabe meines Beispielprogramms beim Abziehen des USB-Kabels ->cb_enumerate y6V (device_identifier 0) disconnected, NOW invalid Könnte nicht hier auch mitgeteilt werden, dass es ein ROTARY_POTI_DEVICE_IDENTIFIER-Bricklet war, das jetzt nicht mehr da ist? Ich finde, mein Programm sollte hier ->cb_enumerate y6V (device_identifier 215) disconnected, NOW invalid ausgeben! Nach dem (Wieder-) Anstecken des USB-Kabels wird enummeriert, alles erscheint zunächst gut: ->cb_enumerate y6V connected, NOW valid, callback set Dann aber wird sofort folgendes ausgegeben ->cb_position_has_changed Position y6V: 150 ->cb_position_has_changed Position y6V: -100 Frage 2: Warum wird mein Callback doppelt aufgerufen? Und dann auch noch beim ersten Mal mit einem ungültigen Poti-Wert 150? (Dass mein callback aufgerufen wird, ist fein! Der zweite Aufruf liefert den richtigen Wert. ) Oder mache ich etwas grundsätzlich falsch hier? Mein Programm hängt an. Gruß, Uwepotitest.c Quote
rtrbt Posted June 4, 2019 at 01:08 PM Posted June 4, 2019 at 01:08 PM Moin, Frage 1: Beim IPCON_ENUMERATION_TYPE_DISCONNECTED wird dem Callback zwar die uid des nicht mehr vorhandenen RotaryPoti übergeben, aber nicht der device_identifier, der immer 0 ist. Warum? Dass nur UID (und enumeration type) gültig sind, liegt daran, dass der Brick Daemon nur diese Werte zwischenspeichert, um sie mit dem Callback rauszugeben. Das ist absichtlich so, da es Fälle gibt, wo nicht mehr Informationen verfügbar sind. Frage 2: Warum wird mein Callback doppelt aufgerufen? Und dann auch noch beim ersten Mal mit einem ungültigen Poti-Wert 150? Das war in der Firmware kaputt. Das Problem ist, dass dein Programm, weil in C, so schnell ist, dass das Callback schon registriert und aktiviert ist, wenn der erste Wert abgefragt wird. Weil die Firmware da die Reihenfolge falsch hatte, wurde erst der (geglättete) Positionswert aus nicht vorhandenen Daten berechnet und danach der erste echte Wert vom Poti gelesen. Teste mal bitte die angehangene Firmware, die löst das Problem bei mir. Erikrotary-poti-bricklet.bin Quote
duaw Posted June 4, 2019 at 02:21 PM Author Posted June 4, 2019 at 02:21 PM Hallo, Erik, yeah, einen Fehler in der Firmware gefunden! Und der ist dann gleich behoben worden: Ja, so passt es auch bei mir. Jetzt musst Du nur noch checken, ob die Kategorie auch woanders noch im Bricklet-Zoo zuschlagen kann. Und: Wer lesen kann, der ist eindeutig im Vorteil ... In diesem Fall haben nur uid und enumeration_type einen gültigen Wert. Stand das schon immer da? Gruß, Uwe Quote
rtrbt Posted June 4, 2019 at 03:13 PM Posted June 4, 2019 at 03:13 PM Habe dir nochmal eine neue Firmware angehangen, da war noch ein Rundungsfehler in dem Fall den du getroffen hattest, der u.U. dazu führt, dass doch zwei Callbacks (das erste eins größer als das zweite) zugestellt werden. Die angehangene Firmware ist identisch zur offiziellen 2.0.3.rotary-poti-bricklet.bin Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.