addon_einbinden
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
addon_einbinden [2014/03/03 10:19] – [Initialisierung und Shutdown] Michael | addon_einbinden [2016/07/05 10:52] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 23: | Zeile 23: | ||
**Da es sich " | **Da es sich " | ||
+ | |||
+ | Sollte in der Basis ein neues Flag verwendet werden, führen wir eine entsprechende Deklaration ein. Eine Doppelbenutzung durch ein AddOn, das der Konvention folgt, deckt der Compiler dann schnell auf. Sollte der Compiler eine Doppelbenutzung aufdecken, so kann man den ' | ||
===== AddOn-Hooks ===== | ===== AddOn-Hooks ===== | ||
Zeile 66: | Zeile 68: | ||
Die Features werden in '' | Die Features werden in '' | ||
+ | {{: | ||
+ | Dort werden sinnige Indices für die in '' | ||
+ | |||
+ | <WRAP center round info 80%> | ||
+ | Im Gegensatz zu CVs sind Features eineindeutige Standardobjekte und damit genehmigungspflichtig. D.h. eine CV kann man definieren, wie man lustig ist, ein Feature nicht. Das ist der Grund, weshalb nur die in bidib_messages.h abgesprochenen und standardisierten Werte erlaubt sind.</ | ||
+ | |||
+ | Zum Lesen der Features stehen die zwei Funktionen aus der Header-Datei '' | ||
+ | {{: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | Wenn ein Host-System eine Nachricht vom Typ: '' | ||
+ | {{: | ||
+ | Soll die Anfrage unterstützt werden, sind die entsprechenden Informationen des SPORT-Accessorys mit den übergebenen Informationen zu setzen und '' | ||
+ | |||
+ | Analog wird verfahren, wenn ein Host-System mit der Nachricht: '' | ||
+ | {{: | ||
+ | Soll die Anfrage unterstützt werden, sind die angeforderten Angaben mit den entsprechenden Informationen des SPORT-Accessorys auszufüllen und '' | ||
==== EEPROM (CV-Daten) ==== | ==== EEPROM (CV-Daten) ==== | ||
Zeile 90: | Zeile 111: | ||
==== Initialisierung und Shutdown ==== | ==== Initialisierung und Shutdown ==== | ||
- | Zur Initialisierung ruft das Basissystem Funktionen des AddOns an vier Stellen im Modul '' | + | Zur Initialisierung ruft das Basissystem Funktionen des AddOns an mehreren |
* Nach Abschluss der Basisinitialisierung und **vor** Freigabe der **Interrupts** die Funktion **'' | * Nach Abschluss der Basisinitialisierung und **vor** Freigabe der **Interrupts** die Funktion **'' | ||
* Beim Herunterfahren die Funktion **'' | * Beim Herunterfahren die Funktion **'' | ||
* Nach Abschluss der gesamten Initialisierung sowie **nach** Freigabe der **Interrupts** und innerhalb einer Task die Funktion **'' | * Nach Abschluss der gesamten Initialisierung sowie **nach** Freigabe der **Interrupts** und innerhalb einer Task die Funktion **'' | ||
- | * Jedesmal nach Initialisierung der BiDiB-Komponente, | + | |
+ | | ||
{{codehilfe: | {{codehilfe: | ||
Die Funktionen sind in der Quelle '' | Die Funktionen sind in der Quelle '' | ||
Zeile 105: | Zeile 127: | ||
Während die Power-Up-Tasks noch laufen, startet das Tasksystem alle angemeldeten Tasks, die als '' | Während die Power-Up-Tasks noch laufen, startet das Tasksystem alle angemeldeten Tasks, die als '' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Zur Synchronsierung mit dem Basissystem wird die Funktion '' | ||
+ | |||
+ | In manchen Fällen ist ein Neustart der Anwendung notwendig, wenn sich z.B. die Struktur des Knotens durch Umkonfiguration geändert hat. Wenn das AddOn dieser BiDiB-Befehl erreicht (oder auch nach einem Neustart der Baugruppe), wird die Funktion: '' | ||
- | In manchen Fällen ist ein Neustart der Anwendung notwendig, wenn sich z.B. die Struktur des Knotens durch Umkonfiguration geändert hat. Wenn das AddOn dieser BiDiB-Befehl erreicht, wird die Funktion: '' | ||
{{: | {{: | ||
+ | |||
Dort können alle Neu-Initialisierungen organisiert werden, die einen Neustart des Knotens notwendig machen. | Dort können alle Neu-Initialisierungen organisiert werden, die einen Neustart des Knotens notwendig machen. | ||
- | Hier am Beispiel der OneControl. Dort wird bei Umkonfigurierung der Ein- und Ausgänge des GPIO-Bausteins ein Neustart nötig. | + | Hier am Beispiel der OneControl, bei der bei Umkonfigurierung der Ein- und Ausgänge des GPIO-Bausteins ein Neustart nötig |
\\ Weitere so genannte Callback-Funktionen im Modul '' | \\ Weitere so genannte Callback-Funktionen im Modul '' | ||
Zeile 154: | Zeile 182: | ||
==== Hilfseingabe ==== | ==== Hilfseingabe ==== | ||
- | Für die Ausführung eines Makros können u.U. interne | + | Die Basis-Firmware unterstützt |
+ | * Meldung über den BiDi-Bus nach einer '' | ||
+ | * Starten von Makros über externe Eingänge | ||
+ | |||
+ | In beiden Fällen wird die Callback-Funktion **'' | ||
{{: | {{: | ||
- | Beachte: Derzeit werden nur die Zustände der ersten 8 Eingänge abgefragt. | + | Beachte: Derzeit werden |
+ | ---- | ||
+ | **Spontane Keyboard-Ereignisse** werden mit dem integrierten **[[softwarebausteine: | ||
---- | ---- | ||
Zeile 191: | Zeile 225: | ||
- '' | - '' | ||
- '' | - '' | ||
- | - In '' | + | - In '' |
+ | - In '' | ||
- In '' | - In '' | ||
- In '' | - In '' | ||
Zeile 242: | Zeile 277: | ||
* **init_addon()** Funktionsaufruf zur Initialisierung **vor** Freigabe de Interrupts | * **init_addon()** Funktionsaufruf zur Initialisierung **vor** Freigabe de Interrupts | ||
* **power_up_addon()** ask zur weiteren Initialsierung **nach** Freigabe der Interrupts | * **power_up_addon()** ask zur weiteren Initialsierung **nach** Freigabe der Interrupts | ||
- | * **close_addon()** Funktion zum Schließen des AddOns insbesondere der Interrupts | + | * **init_finished_addon()** Abfrage, ob AddOn mit INitialisierung fertig ist |
* **restart_addon()** Funktion zum Neustart nach Knoten-Reset | * **restart_addon()** Funktion zum Neustart nach Knoten-Reset | ||
+ | * **close_addon()** Funktion zum Schließen des AddOns insbesondere der Interrupts | ||
== Betrieb == | == Betrieb == |
addon_einbinden.1393838361.txt.gz · Zuletzt geändert: 2016/07/05 10:46 (Externe Bearbeitung)