Hallo zusammen, ich beschäftige mich zurzeit mit der BitCloud von Atmel. Darin werden zur Kommunikation zwischen Anwenderebene und Stack vor allem asynchrone Callbackfunktionen benutzt. Mir geht es dabei vor allem zu vestehen, warum dieses Prinzip als asynchron bezeichnet wird. Dazu habe ich eine Grafik angefügt, die (auf der rechten Seite) einen asynchronen Zugriff auf den Stack darstellt. So verstehe ich das Ganze: Zunächst wird die Funktion ZDO_StartNetworkReq() auf Anwenderebene aufgerufen und auf der ZDO-Ebene ausgeführt. Wenn die Funktion das gewünschte Ergebnis hat (Event), wird die Callbackfunktion ZDO_StartNetworkConf() auf der ZDO_Ebene aufgerufen und auf der Anwenderebene ausgeführt. Nach Ausführung kehrt die Funktion zur aufrufenden Ebene (ZDO) zurück. Bis hierhin ist es asynchron, das sehe ich ein, wie ja auch auf der Grafik zu sehen ist. Nur ist der erste Aufruf auf der Anwenderebene passiert und hierhin müsste doch letztendlich das Programm zurückspringen. Und damit ist der Ablauf synchron?! Hoffe ich habe mich verständlich ausgedrückt. Wo liegt mein Gedankenfehler?
Angehängte Dateien:
-
callback.GIF
37 KB
Ich bringe den Thread nochmal hoch. Denke hier gibt es einige Leute die sich damit auskennen. Danke schonmal!
Asynchron: sofort Synchron: zu einem bestimmten Takt synchron Ein Callback wird ja sofort ausgeführt, wenn das triggernde Ereignis eintritt, ist daher asynchron. Synchron wäre, wenn z.B. ein Timer alle 1s prüft, ob in der Zwischenzeit der Trigger erfolgte und dann erst den Callback aufruft. Peter
Ohne jetzt die BitCloud zu kennen... Generell verstehe ich synchron und asynchron in dem Zusammenhang als blockierend und nicht blockierend Aufrufe. Eine synchrone Funktion erwartet einen Rückgabewert und wartet so lange, bis da was kommt. So lange is der Thread, in dem die synchrone Fkt gerufen wurde, beblockt. Asynchrone Funktionen haben keinen Rückgabewert (zumindest nix was lange dauert) sondern teilen per Funktionsaufruf mit, das was passiert ist (Event, Callback, Funktionspointer, wie auch immer). Jetzt auf das obige Beispiel bezogen würd ich sagen das deine APL irgendwann ZDO_StartNetworkReq() aufruft, und weil das länger dauert das asynchron realisiert wurde. Irgendwann kommt dann der Callback bei der APL an, der dir sagt, das alles ok ist. Die APL ist in dieser Zeit jedoch nicht blockiert (das wäre sie bei synchron). Daher springt auch nix zurück, was du oben meintest... Hilft das was??? Nico
Danke für die ausführliche Erklärung! Nico B. schrieb: >Die APL ist in dieser Zeit > jedoch nicht blockiert (das wäre sie bei synchron). Daher springt auch > nix zurück, was du oben meintest... Genau da liegt mein Verständnisproblem. Während die ZDO-Ebene auf das Ereignis wartet kann theoretisch währenddessen auf Anwenderebene etwas anderes ausgeführt werden? Aber es gibt ja nur einen Thread. Wird dieser sozusagen freigegeben und an die nächste Ebene vergeben, die etwas ausführen möchte? Wenn das so ist, verstehe ich nicht wie das im Code realisiert wird.
Rainer: Wenn ich Dich richtig verstehe möchtest Du wissen, warum im Diagramm bei dem ZDO_StartNetworkReq()-Auruf kein Pfeil zurück in Deine Applikation geht?
Peter Dannegger schrieb: > Asynchron: sofort > Synchron: zu einem bestimmten Takt synchron > > Ein Callback wird ja sofort ausgeführt, wenn das triggernde Ereignis > eintritt, ist daher asynchron. > > Synchron wäre, wenn z.B. ein Timer alle 1s prüft, ob in der Zwischenzeit > der Trigger erfolgte und dann erst den Callback aufruft. Ich würde es allerdings genau andersherum sehen. sofort -> Callback synchron zum Ereignis später -> Callback asynchron zum Ereignis
mio schrieb: > Wenn ich Dich richtig verstehe möchtest Du wissen, warum im Diagramm bei > dem ZDO_StartNetworkReq()-Auruf kein Pfeil zurück in Deine Applikation > geht? Ja, unter anderem. Da die Anwednung an einem Punkt unterbrochen wurde, muss sie ja auch dort fortgeführt werden. Aber das ist im Falle eines Callbacks scheinbar nicht so. Ich hätte vermutet,dass das Programm zum initialen Aufrufer zurückkehrt und das war die APL Ebene.
ich kenn die API jetzt nicht aber: Wenn das ganze synchron ist, dann machst du einen Aufruf und der Aufruf kehrt erst zurück wenn das Ergebnis da ist. Das kann z.B. bei Kommunikation oder bestimmten Peripheriegeräten relativ lange dauern. Asynchron startest du mit dem Aufruf deine Verarbeitung und kannst in deinem Hauptprogramm weiterarbeiten (z.B. prüfen ob ein taster gedrückt wurde, Messwerte aufnehmen, oder was auch immer) und erst wenn die Aktion in deiner API beendet wurde wird eben 'asynchron' die Antwort via call-back) zurückgeschrieben. Dinge wie UART Kommunikation (in der intelligenten Interrupt gesteuerten Variante) oder A/D Wandeln mittels Interrupt sind auch asynchron. Dazu brauchst du nicht mehrere Threads. Auf dem µC hast du die quasi Parallelität durch Interrupts.
Ich denke es ist so (ohne im Code geschaut zu haben :)): 1. Mit dem Aufruf ZDO_StartNetworkReq() wird ZDO aufgefordert das Netzwerk hochzufahren, als Argument wird ein Funktionspointer übergeben, Dein Callback. 2. Der Ablauf verzweigt wieder in die Anwendung. 3. Anwendungscode kann ausgeführt werden. -> Das Netzwerk ist aber noch nicht bereit. 4. Irgendwann wird vom ZDO Dein Callback aufgerufen -> Netzwerk ist oben und kann genutzt werden. --------------------------- P.S.: Kann man das SDK irgendwo runterladen um genau im Code nachschauen zu können?
Rainer B. schrieb: > Da die Anwednung an einem Punkt unterbrochen wurde, muss sie ja auch > dort fortgeführt werden. Aber das ist im Falle eines Callbacks scheinbar > nicht so. Ich hätte vermutet,dass das Programm zum initialen Aufrufer > zurückkehrt und das war die APL Ebene. Sie muß nur bei synchronen aka blockierenden Funktionen dort fortgeführt werden. Bei asynchronen Events kann das (kommt auf das System an) z.B. ein Funktionsaufruf im Hauptthread sein (ein Callback) oder das triggern eines Interrupts. Du rufst aber eine Methode auf, sobald dein Aufruf in abgearbeitet ist.
Danke für eure Erklärungen Ich denke ich hab's verstanden:-)
mio schrieb: > Kann man das SDK irgendwo runterladen um genau im Code nachschauen zu > können? Die BitCloud von Atmel ist Freeware. Allerdings sind die ZigBee spezifischen Ebenen sprich ZDO und NWK nicht als Quellcode verfügbar.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.