Stabiler Ansatz mit C-Bindings

[duaw]

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ß, Uwe

potitest.c

[rtrbt]

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.

 

Erik

rotary-poti-bricklet.bin

[duaw]

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

[rtrbt]

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