DrvManager

Der DrvManager ist die Manager-Klasse des Treibers. Sie ist ihrerseits von der Basis-Klasse Manager abgeleitet.

Der DrvManager erbt vom Manager die statischen Zeiger auf den Datenpunkttyp-Container und den Datenpunkt-Container. Darüber hinaus enthält er statische Zeiger auf den Datenpunkt-Config-Manager sowie auf die Klassen HWMapper, HWService und PollGroupList. Weiters enthält er einen Zeiger auf ein Array von DpConfigNrType´s, die zur Initialisierung benötigt werden.

Für alle diese statischen Zeiger gibt es virtuelle Funktionen, welche die Objekte anlegen und installieren (den Zeiger dafür in der Klasse DrvManager vermerken) - nämlich die install_$$$-Funktionen (siehe Kapitel 1). Da im Normalfall zumindest für das HWService-Objekt und den-HWMapper eine eigene Klasse implementiert werden muss, muss auch eine eigene Klasse für den DrvManager implementiert werden, die die install_HWMapper()- und die install_HWService()-Funktion überschreibt.

Wird die DrvManager (Basisklasse) - mainProcedure() aufgerufen (diese Funktion wurde in der von DrvManager abgeleiteten Klasse nicht überschrieben), werden folgende Schritte durchgeführt:

Die Funktion init() der DrvManager-Klasse wird aufgerufen (hier werden mittels der install_$$$- Funktionen die statischen Pointer initialisiert)

• Eine direkte Verbindung zum Data-Manager wird aufgebaut und die Initialisierung des Datenpunkt-Typ-Containers und des Datenpunkt-Containers (für die Konfigs) durchgeführt.

• Zu den Namen der internen Datenpunkte werden von der Datenbank die Datenpunkt-Identifier abgefragt. Da der Treiber in den Messages (z.B. in ValueChanges oder HotLinks) keine Dp-Namen sondern nur Dp-Identifier verwenden kann, muss er zu Beginn vom Data-Manager die Umwandlung der Namen in DpIdentifier angefordern und die erhaltenen DpIdentifier speichern. -> siehe Beschreibung von DrvRsrce!

• HWService-Objekt wird initialisiert.

• Der Treiber baut eine Verbindung zum Eventmanager auf und meldet sich für alle Datenpunkt-Originalwerte mit als Ausgang definierter Peripherieadresse beim Eventmanager an.

• Nun wird die (virtuelle) Funktion mainLoop aufgerufen.

Die Funktion mainLoop() des DrvManagers deckt folgende Funktionalität ab:

• Reconnect zum Event-Manager, wenn die Verbindung unterbrochen wurde

• Aufruf des Dispatchers (Bearbeiten der Versendeaufträge des Event-Managers)

• Polling (Bearbeitung zyklischer Datenabfragen)

• Aufruf der (virtuellen) Funktion workProc() des HWService-Objekts (Bearbeitung der ankommenden Daten)

Dies wird in einer Schleife solange durchgeführt, bis der internalMode des DrvManagers auf DRVMODE_EXITING gesetzt wird. (z.B. durch Drücken von Ctrl-C)

Die Funktion toDp(HWObject *, HWObject *) ist ebenfalls virtuell, muss aber normalerweise nicht überschrieben werden. Sie dient der Behandlung ankommender Daten. Diese werden in toDp(..) vom Rohwert in den Ingenieurwert umgewandelt, gegebenenfalls geglättet, und an den Event-Manager weitergeleitet.

Die Funktion toHW(DpHLGroup *) behandelt das Verschicken von Datenpunkten in Befehlsrichtung. Sie erhält vom Eventmanager eine Gruppe von Datenpunkten (bei Gruppenanmeldung), die verschickt werden sollen. Die Funktion erzeugt ein HWObject oder die treiberspezifische Entsprechung, und ruft mit diesem die Funktion writeData(HWObject) des HWService-Objektes auf, die das Objekt an die Peripherie verschickt.

Die virtuelle Methode getAttribs2Connect(..) liefert für eine angegebene Peripherieadresse die Attribute, für die sich der Treiber beim Eventmanager anmelden möchte. Im Normalfall wird dies nur der Originalwert sein. Soll zusätzlich zum Beispiel die Quellzeit angefordert werden, so muss der spezielle Treiber diese Funktion entsprechend überschreiben.

Beispiel

unsigned int getAttribs2Connect( const PeriphAddr *) const
{ // für Originalwert und Zeit
  return DRVCONNMODE_VALUE | DRVCONNMODE_TIME;
}

Außer für Originalwert und Zeit kann die Anmeldung für die folgenden Statusbits erfolgen:

• DRVCONNMODE_GA (Generalabfrage-Bit)

• DRVCONNMODE_EA (Einzelabfrage-Bit)

• DRVCONNMODE_INVALID (Invalid-Bit)

• DRVCONNMODE_USER1 (User-Bit 1)

• DRVCONNMODE_USER2 (User-Bit 2)

• DRVCONNMODE_USER3 (User-Bit 3)

• DRVCONNMODE_USER4 (User-Bit 4)

  ...

• DRVCONNMODE_USER29 (User-Bit 29)

• DRVCONNMODE_USER30 (User-Bit 30)

• DRVCONNMODE_USER31 (User-Bit 31)

• DRVCONNMODE_USER32 (User-Bit 32)

Hinweis

In größeren Projekten kann es dazu kommen, dass die Initialisierung der Treiberspezifischen Konfiguration mehr Zeit in Anspruch nimmt. Dies führt dazu, dass in manchen Fällen bestimmte Treiber Implementierungen längere brauchen um den Normalbetreib aufnehmen zu können. Die kann zu dem Problem führen, dass ein Treiber Informationen verwenden will, welche noch nicht vorhanden sind (z.B. Der Treiber versucht AlertService::setAlert() aufzurufen obwohl die entsprechende _alert_hdl Konfiguration noch nicht geladen wurde).

Ein spezifischer Treiber kann die Callback Methode DrvManager::connectQueueDone() überschreiben um eine Information zu erhalten, sobald die Initialisierung abgeschlossen wurde. Nur nach dem Aufruf dieser Funktion sollte sich die Treiber Implementierung darauf verlassen, dass die benötigten Informationen vorhanden sind.