Callbacks - Ein Vorschlag: Übergabe von data pointers

[cfranz]

Ich bin gerade dabei, einen Cocoa-Layer zu schreiben, der auf den normalen Interfaces sitzt und die Verwendung der Bricks noch bequemer machen soll.

 

So ist es z.b relativ einfach mit dem Layer so etwas zu machen:

 

// theConnection ist ein cocoa-objekt, welches IPconnection kapselt

 

NSArray *alleBricklets = [theConnection getAll]; // alle momentan angeschlossene bricklets

 

TinkerDevice *aDevice

for (aDevice in alleBricklets) {

  if ([[aDevice deviceName] containsString:@"Relay"]) {

      // mach etwas mit dem relay, egal ob dual, quad oder indu

  }

}

 

So weit, so gut. Allerdings laufe ich bei allen callbacks in das gleiche Problem. Solange die Stacks klein sind, ist dieses Problem irrelevant, oder kann spezifisch gelöst werden.

Bei grösseren stacks oder komplexeren Programmen wäre es gut, wenn den callbacks noch ein (void *) mitgegeben werden kann, der zur Interrupt/Callback-zeit zurückgegeben wird.

 

der callback sieht also immer so (ähnlich) aus:

 

void cb_Whatevah (..., void *data) {}

 

und der register call

 

void device_register_callback( ..., void *callback, void *data)

 

Auf diese Art kann der Interrupt/Callback-handler Zugriff erhalten auf den Speicherbereich, der mit diesem Callback assoziiert ist.

In dem fall von cocoa ist es natürlich das Objekt, das diesen callback angefordert hat.

 

Warum das Ganze?

Im Prinzip brauche ich eine Möglichkeit, während eines callbacks herauszufinden, welches Bricklet (wenn mehr als eines vom gleichen Typ verwendet werden) den callback auslöst, um dann das richtige Objekt zuzuordnen. Es würde also auch ausreichen, wenn während des Callbacks die UID des Bricklets verfügbar ist, das den Interrupt ausgelöst hat. Die (void *) Variante ist etwas genereller verwendbar.

 

Ich bin sicher, dass ich ich die Sources für meine Bedürfnisse entsprechend ändern kann. Das Problem ist dann, dass der Cocoa Layer nicht mehr mit den 'echten' TF sources kompatibel ist. Und das gibt dann ein ziehmliches Gewürge für jeden, der den Layer verwenden will (grosskotzig setze ich mal voraus, dass es jemanden ausser mir gibt, der an sowas überhaupt Interesse hat )

 

Oder habe ich etwas elementares übersehen und das gibt es schon längst?

 

-ch

 

[cfranz]

Es ist immer blöd auf seinen eigenen Post zu antworten, sorry.

 

Was ich eigentlich anregen möchte:

In einer neuen, späteren Version der APIs für alle Bricklets/Bricks sollte einer generelle Erweiterung aller callbacks um (void *) oder UID aufgenommen werden.

 

-ch

 

[photron]

Richtig, das Problem betrifft hier im speziellen C. Zum Beispiel in Python kann man da eine Closure verwenden um der Callbackfunktion Kontext mitzugeben. In C funktioniert das nicht.

 

Da wir ihm Rahmen von Protokoll 2.0 eh API brechen werden, werden wir auch ein user_data Parameter für die register_callback Funktion hinzufügen.

[cfranz]

Klasse!

 

... wenn ich schon dabei bin: der Cocoa-Layer sollte transparent diese callbacks verwalten, weshalb ich auf das Problem gestossen bin. Ich selber habe es nicht ausprobiert (das Bricklet ist noch auf dem Weg zu mir), aber kann ich momentan (oder unter API 2.0) *zwei* oder mehr unterschiedliche callbacks für das gleiche bricklet aktiv haben. Z.B. für den Entfernungsmesser einen, der feuert, wenn die Distanz < 100 mm und einen anderen, wenn die distanz > 700mm? Ich frage nur, weil für eine generelle Verwaltung dieser callbacks im Cocoa Layer dann ein 'unregister' eine gute Idee wäre.

 

Gruss,

-ch

 

[photron]

Ein Callback kann nur eine Konfiguration haben. Dass heißt, der Distance Reached Callback kann entweder für < 100 mm oder > 700 mm konfiguriert werden. Du kannst es natürlich auch so konfigurieren, dass der Callback ausgelöst wird wenn die Distanz zwischen 100 und 700 mm liegt oder außerhalb des 100 und 700 mm Bereichs. Insgesamt kannst du nur eine Bedingung für den einen Callback definieren.

 

unregister_callback gibt es: register_callback(id, NULL)