Author Topic: Stabiler Ansatz mit C-Bindings  (Read 902 times)

duaw

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Stabiler Ansatz mit C-Bindings
« on: June 04, 2019, 12:50:27 »
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:
Code: [Select]
->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
Code: [Select]
->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
Code: [Select]
->cb_enumerate y6V (device_identifier 215) disconnected, NOW invalid
ausgeben!

Nach dem (Wieder-) Anstecken des USB-Kabels wird enummeriert, alles erscheint zunächst gut:

Code: [Select]
->cb_enumerate y6V  connected, NOW valid, callback set
Dann aber wird sofort folgendes ausgegeben
Code: [Select]
->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

rtrbt

  • Tinkerforge Staff
  • Administrator
  • Full Member
  • *****
  • Posts: 115
    • View Profile
Re: Stabiler Ansatz mit C-Bindings
« Reply #1 on: June 04, 2019, 15:08:44 »
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

duaw

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Re: Stabiler Ansatz mit C-Bindings
« Reply #2 on: June 04, 2019, 16:21:16 »
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 ...
Quote
In diesem Fall haben nur uid und enumeration_type einen gültigen Wert.

Stand das schon immer da?

Gruß, Uwe

rtrbt

  • Tinkerforge Staff
  • Administrator
  • Full Member
  • *****
  • Posts: 115
    • View Profile
Re: Stabiler Ansatz mit C-Bindings
« Reply #3 on: June 04, 2019, 17:13:29 »
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.