Benutzer-Werkzeuge

Webseiten-Werkzeuge


addon_einbinden

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
addon_einbinden [2014/02/01 18:09] – [Vorgehen] Michaeladdon_einbinden [2016/07/05 10:52] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 23: Zeile 23:
  
 **Da es sich "nur" um eine Konvention handelt, ist hier die Disziplin des Einzelnen gefordert!** **Da es sich "nur" um eine Konvention handelt, ist hier die Disziplin des Einzelnen gefordert!**
 +
 +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 'konkurrierenden' Nutzer einfach ausfindig machen, wenn man vor //#error Port conflict A7// temporär ein //#define I_NEED_PORTA7 1234// setzt. Der Compiler zeigt dann die Stelle mit //previous define was here// an.
  
 ===== AddOn-Hooks ===== ===== AddOn-Hooks =====
Zeile 63: Zeile 65:
  
 ==== Baugruppen-Fähigkeiten (Features) ==== ==== Baugruppen-Fähigkeiten (Features) ====
-"//... Über features teilt die Hardware dem PC-Programm ihre Fähigkeiten mit (also z.B. 'ich kann Lokadresse UND Richtung erkennen'). Das kann eine Eigenschaft der Hardware sein (wer kann, der kann), das kann aber auch explizit abgewählt werden - weil eben z.B. eine Dreileiteranlage angeschlossen ist, wo die Richtungsinformation des Belegtmelders wertlos ist. Features sind in der Norm auf bidib.org erläutert...//" (siehe [[http://www.bidib.org/protokoll/bidib_general.html#T4|ProtokollKapitel Nachrichten]])+"//... Über features teilt die Hardware dem PC-Programm ihre Fähigkeiten mit (also z.B. 'ich kann Lokadresse UND Richtung erkennen'). Das kann eine Eigenschaft der Hardware sein (wer kann, der kann), das kann aber auch explizit abgewählt werden - weil eben z.B. eine Dreileiteranlage angeschlossen ist, wo die Richtungsinformation des Belegtmelders wertlos ist. Features sind in der Norm auf bidib.org erläutert...//" (siehe [[http://www.bidib.org/protokoll/bidib_general.html|BiDiBein universelles Steuerprotokoll für Modellbahnen]])
  
 Die Features werden in ''addon_features.h'' definiert und müssen den Fähigkeiten der Baugruppe angepasst werden. Die Features werden in ''addon_features.h'' definiert und müssen den Fähigkeiten der Baugruppe angepasst werden.
 +{{:codehilfe:oc_features_h.jpg|}}
 +Dort werden sinnige Indices für die in ''bidib_message.h'' vorgegebenen Features definiert. Die Tabelle feature[] enthält den aktuellen Wert des Features und seine Grenzwerte (min/max). Für eine weitere Verarbeitung kann eine ''notify_function'' angegeben werden. (Im Beispiel gibt es keine.)
 +
 +<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.</WRAP>
 +
 +Zum Lesen der Features stehen die zwei Funktionen aus der Header-Datei ''features.h'' zur Verfügung:
 +{{:codehilfe:oc_get_feature_index.jpg| }} Mit Hilfe dieser Funktion erhält man über die in ''bidib_messages.h'' vorgegebenen Features den Index auf die interne Tabelle. Ist das Feature ungültig bzw. steht es nicht in der tabelle, wird -1 geliefert, andererseits der Index.
 +
 +{{:codehilfe:oc_get_feature_index_value.jpg |}} Mit dem oben erhaltenen Index wird mit dieser Funktion der Wert des Features gelesen. Diese Funktion sollte nur aufgerufen werden, wenn der oben erhaltene Index größer oder gleich 0 ist.
 +
 +
 +Wenn ein Host-System eine Nachricht vom Typ: ''MSG_LC_CONFIG_SET'' abschickt, wird die Funktion ''config_sport_addon'' aufgerufen:
 +{{:codehilfe:oc_config_sport_addon.jpg|}}
 +Soll die Anfrage unterstützt werden, sind die entsprechenden Informationen des SPORT-Accessorys mit den übergebenen Informationen zu setzen und ''1'' zu liefern. Anderenfalls reicht die Rückgabe einer ''0''.
 +
 +Analog wird verfahren, wenn ein Host-System mit der Nachricht: ''MSG_LC_CONFIG_GET'' die SPORT-Eigenschaften anfordert, dann wird die Funktion ''addon_sport_query'' aufgerufen:
 +{{:codehilfe:oc_addon_sport_query.jpg|}}
 +Soll die Anfrage unterstützt werden, sind die angeforderten Angaben mit den entsprechenden Informationen des SPORT-Accessorys auszufüllen und ''1'' zu liefern. Anderenfalls reicht die Rückgabe einer ''0''.
  
 ==== 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 ''addon.c'' auf:+Zur Initialisierung ruft das Basissystem Funktionen des AddOns an mehreren Stellen im Modul ''addon.c'' auf:
   * Nach Abschluss der Basisinitialisierung und **vor** Freigabe der **Interrupts** die Funktion **''init_addon()''**   * Nach Abschluss der Basisinitialisierung und **vor** Freigabe der **Interrupts** die Funktion **''init_addon()''**
   * Beim Herunterfahren die Funktion **''close_addon()''**   * Beim Herunterfahren die Funktion **''close_addon()''**
   * Nach Abschluss der gesamten Initialisierung sowie **nach** Freigabe der **Interrupts** und innerhalb einer Task die Funktion **''power_up_addon()''**   * Nach Abschluss der gesamten Initialisierung sowie **nach** Freigabe der **Interrupts** und innerhalb einer Task die Funktion **''power_up_addon()''**
-  * Jedesmal nach einem Befehl, den Knoten zurückzusetzen, wird die Funktion **''restart_addon()''** aufgerufen.+  * Während der Power-Up-Phase wird der Zustand der Initialisierung in der Funktion **''init_finished_addon''** abgefragt. Die Initialisierung wird genau dann fortgesetzt, wenn hier 0 geliefert wird! 
 +  * Jedesmal <del>nach Initialisierung der BiDiB-Komponente, also sowohl nach einem Neustart als auch</del> nach dem Befehl, den Knoten zurückzusetzen, wird die Funktion **''restart_addon()''** aufgerufen.//(seit V.00.06)//
 {{codehilfe:oc_addon_c.jpg |}} {{codehilfe:oc_addon_c.jpg |}}
 Die Funktionen sind in der Quelle ''addon.c'' vorbereitet. Die Funktionen sind in der Quelle ''addon.c'' vorbereitet.
Zeile 105: Zeile 127:
  
 Während die Power-Up-Tasks noch laufen, startet das Tasksystem alle angemeldeten Tasks, die als ''ready'' gekennzeichnet wurden! Um Initialisierungskonflikte zu vermeiden, dürfen die vom AddOn abhängigen Taks erst zum Schluss der Power-Up-Task freigegeben werden! Während die Power-Up-Tasks noch laufen, startet das Tasksystem alle angemeldeten Tasks, die als ''ready'' gekennzeichnet wurden! Um Initialisierungskonflikte zu vermeiden, dürfen die vom AddOn abhängigen Taks erst zum Schluss der Power-Up-Task freigegeben werden!
 + 
 +{{:codehilfe:oc_addon_init_finished.jpg |}}
 +
 +Zur Synchronsierung mit dem Basissystem wird die Funktion ''init_finished_addon'' aufgerufen. Das Verfahren ist notwendig, wenn ein AddOn erst im weiteren Programmablauf (z.B. während einer eigenen länger dauernden Task) die Initialisierung fertig stellen kann.
 +
 +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: ''restart_addon()'' aufgerufen.
  
-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: ''restart_addon()'' aufgerufen. 
 {{:codehilfe:oc_restart_addon.jpg |}} {{:codehilfe:oc_restart_addon.jpg |}}
 +
 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 wird.
  
 \\ Weitere so genannte Callback-Funktionen im Modul ''addon.c'' werden weiter unten in den Kapiteln: [[addon_einbinden#Accessory-Behandlung|Accessory-Behandlung]], [[addon_einbinden#Makroausführung|Makroausführung]] und [[addon_einbinden#Hilfseingabe]] erläutert. \\ Weitere so genannte Callback-Funktionen im Modul ''addon.c'' werden weiter unten in den Kapiteln: [[addon_einbinden#Accessory-Behandlung|Accessory-Behandlung]], [[addon_einbinden#Makroausführung|Makroausführung]] und [[addon_einbinden#Hilfseingabe]] erläutert.
Zeile 154: Zeile 182:
  
 ==== Hilfseingabe ==== ==== Hilfseingabe ====
-Für die Ausführung eines Makros können u.U. interne Eingänge konfiguriert werden. Falls das AddOn diese Fähigkeit hat, muss es in der Callback-Funktion **''check_input_addon(...)''** den Zustand des übergebenen Eingangs liefern. Hat das AddOn diese Fähigkeit nicht, muss FALSE geliefert werden.+Die Basis-Firmware unterstützt Eingänge in zwei Arten: 
 +  * Meldung über den BiDi-Bus nach einer ''MSG_LC_KEY_QUERY''-Nachricht 
 +  * Starten von Makros über externe Eingänge 
 + 
 +In beiden Fällen wird die Callback-Funktion **''check_input_addon(...)''** aufgerufen. Sie muss den Zustand des übergebenen Eingangs liefern. Hat das AddOn diese Fähigkeit nicht, muss FALSE geliefert werden.
 {{:codehilfe:oc_check_input_addon.jpg|}} {{:codehilfe:oc_check_input_addon.jpg|}}
-Beachte: Derzeit werden nur die Zustände der ersten 8 Eingänge abgefragt.+Beachte: Derzeit werden für die Makroausführung nur die Zustände der ersten 8 Eingänge abgefragt.
  
 +----
 +**Spontane Keyboard-Ereignisse** werden mit dem integrierten **[[softwarebausteine:Event-System|Event-System]]** realisiert.
 ---- ----
  
Zeile 191: Zeile 225:
     - ''addon_cv_data.h'' Inhalte festlegen     - ''addon_cv_data.h'' Inhalte festlegen
     - ''addon_cv_features.h'' Fähigkeiten festlegen     - ''addon_cv_features.h'' Fähigkeiten festlegen
-  - In ''addon.c/h'' Initialisierung (inkl. Power-Up) und "Shutdown" sowie Neustart veranlassen+  - In ''addon.c'' Initialisierung (inkl. Power-Up) und "Shutdown" sowie Neustart veranlassen 
 +  - In ''addon.c'' Anfragen zu Features verwalten
   - In ''addon_tasklist.h'' Tasks definieren   - In ''addon_tasklist.h'' Tasks definieren
   - In ''addon.c'' "Schlusswort" und Makrofunktionen sowie gfls. Eingangsschalter für Makros initiieren   - In ''addon.c'' "Schlusswort" und Makrofunktionen sowie gfls. Eingangsschalter für Makros initiieren
Zeile 198: Zeile 233:
 ==== Hooks ==== ==== Hooks ====
 === Definitionen === === Definitionen ===
 +== Versionsdaten ==
 +  * **MAIN_VERSION**         Hauptversionsnummer
 +  * **SUB_VERSION**          Unterversionsnummer
 +  * **COMPILE_RUN**          Kompilierlauf
 +
 +  * **BUILD_YEAR**           Herstellungsdatum: Jahr
 +  * **BUILD_MONTH**          Herstellungsdatum: Monat
 +  * **BUILD_DAY**            Herstellungsdatum: Tag
 +
 == Baugruppenkennzeichnung == == Baugruppenkennzeichnung ==
   * **BIDIB_VENDOR_ID**      vendor ID = 13   * **BIDIB_VENDOR_ID**      vendor ID = 13
Zeile 204: Zeile 248:
   * **CLASS_OCCUPANCY**      occurence of occupancy messages (0/1=no/yes)   * **CLASS_OCCUPANCY**      occurence of occupancy messages (0/1=no/yes)
   * **CLASS_SWITCH**         occurence of switch messages (0/1=no/yes)   * **CLASS_SWITCH**         occurence of switch messages (0/1=no/yes)
 +
 +== Allgemeine Definitionen ==
 +siehe **''addon_model.h''**
 +  * Aktiviert Zusatzfunktionen aus der Basis-Software, z.B. Servos (**''SERVO_ENABLED''**), LED-Blinken (**''BLINK_MORSE_ENABLED''**).
 +  * Notwendige Angaben, z.B. über die Anzahl von Ein- und Ausgängen, z.B. **''NUM_OF_INPUTS''**, **''NUM_OF_SPORTS''**
 +
 +== Fähigkeiten ==
 +siehe **''addon_features.h''**
 +  * Fähigkeiten des AddOns laut [[http://www.bidib.org/protokoll/bidib_general.html|BiDiB, ein universelles Steuerprotokoll für Modellbahnen]], z.B. **''FEATURE_STRING_SIZE''** oder **''FEATURE_CTRL_INPUT_COUNT''**.
  
 == Taskverwaltung cortos == == Taskverwaltung cortos ==
Zeile 210: Zeile 263:
   * **ADDON_TASKLIST**   Taskdefinitionen   * **ADDON_TASKLIST**   Taskdefinitionen
   * **ADDON_FIFOS**   FIFO-Definitionen   * **ADDON_FIFOS**   FIFO-Definitionen
 +
 +== CV-Werte ==
 +  * EEPROM Version, Herstellerkennzeichnung, ... CV1-CV7
 +  * (Reserviert CV8-CV69)
 +  * Allgemeine Einstellungen CV70
 +  * (Reserviert CV71-80)
 +  * Servos (wenn konfiguriert) ab CV81
 +  * Accessorys (wenn konfiguriert) ab CV209
 +  * **AddOn spezifische Werte ab CV389**
  
 === Funktionen === === Funktionen ===
 == Start und Stopp == == Start und Stopp ==
-  * **addon_init()** Funktionsaufruf zur Initialisierung **vor** Freigabe de Interrupts +  * **init_addon()** Funktionsaufruf zur Initialisierung **vor** Freigabe de Interrupts 
-  * **addon_power_up()** ask zur weiteren Initialsierung **nach** Freigabe der Interrupts +  * **power_up_addon()** ask zur weiteren Initialsierung **nach** Freigabe der Interrupts 
-  * **addon_close()** 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 
 +  * **close_addon()** Funktion zum Schließen des AddOns insbesondere der Interrupts
  
 == Betrieb == == Betrieb ==
   * **performAddOnMacro()** Ausführen der Makros eines AddoOns   * **performAddOnMacro()** Ausführen der Makros eines AddoOns
 +  * **accessoryStateAddOn()** "Schlusswort" bei Beendigung des Accessorys
 +  * **check_input_addon()** Zustandsabfrage der ersten 8 Eingänge zum Makrostart
  
 == Debug-Schnittstelle == == Debug-Schnittstelle ==
addon_einbinden.1391274570.txt.gz · Zuletzt geändert: 2016/07/05 10:46 (Externe Bearbeitung)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki