DrvManager

The DrvManager is the manager class of the driver. It is itself derived from the base class manager.

The DrvManager inherits from the manager the static pointers to the data point type container and the data point container. In addition, it contains static pointers to the data point config manager and to the classes HWMapper, HWService and PollGroupList. It also contains a pointer to an array of DpConfigNrTypes, which are needed for initialization.

For all these static pointers there are virtual functions, which create and install the objects (note the pointer for this in the class DrvManager) - namely the install_$$$ functions (see chapter 1). Since in the normal case a separate class must be implemented at least for the HWService object and the HWMapper, a separate class must also be implemented for the DrvManager, and will overwrite the install_HWMapper()- and the install_HWService() function.

When the DrvManager (Base class) - mainProcedure() is called (this function was not overwritten in the class derived from DrvManager), the following steps are executed:

The function init() from the DrvManager class is called up (the static pointers are initialized here using the install_$$$ functions)

  • A direct connection to the data manager is established, and initialization of the data point type container and the data point container (for the config) is performed.

  • The data point identifiers are queried from the database for the names of the internal data points. Since the driver cannot use any DP names but only DP identifiers in the messages, it has to request the conversion of names to dpidentifiers from the data manager and has to save the received dpidentifiers -> see description of DrvRsrce!

  • The HWService object is initialized.

  • The driver sets up a connection to the event manager and registers with the event manager for all data point original values with peripheral address defined as outlet.

  • The (virtual) function mainLoop is now called up.

The DrvManager mainLoop() function covers the following functionality:

  • Reconnect to the event manager, when the connection has been interrupted

  • Call of the dispatcher (processing of event manager dispatch orders)

  • Polling (processing of cyclical data queries)

  • Call of the (virtual) function workProc() of the HWService object (processing of incoming data)

This is executed in a loop until the internal mode of the DrvManager is set to DRVMODE_EXITING. (e.g. by pressing Ctrl-C)

The function toDp(HWObject *, HWObject *) is likewise virtual, but must not normally be overwritten. It is used for handling incoming data. This is converted in toDp(..) from the raw value to the engineering value, smoothed if necessary and forwarded to the event manager.

The function toHW(DpHLGroup *) handles the sending of data points in the command direction. It receives from the event manager a group of data points (in group login) which are to be sent. The function generates a HW object or the driver-specific equivalent, and with this calls the writeData(HWObject) function of the HWService Object, which sends the object to the periphery.

The virtual method getAttribs2Connect(..) delivers for a given peripheral address the attributes for which the driver should register with the event manager. This will normally be only the original value. If the source time should also be requested, for instance, the special driver must overwrite this function accordingly.

Example

unsigned int getAttribs2Connect( const PeriphAddr *) const
{ 
  // for original value and time 
  return DRVCONNMODE_VALUE | DRVCONNMODE_TIME;
}

A s well as for original value and time, the registration can occur for the following status bits:

  • DRVCONNMODE_GA (General query bit)

  • DRVCONNMODE_GA (Single query bit)

  • DRVCONNMODE_GA (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)

Note

In large projects initialization of driver specific configuration may take a significant amount of time. At times this takes longer than necessary for a specific driver implementation to commence with normal operation. This poses a problem if a driver tries to use information it hasn't yet acquired (e.g. the driver tries to call AlertService::setAlert() when the corresponding _alert_hdl configuration has not been loaded.)

A specific driver may want to override the callback method DrvMananger::connectQueueDone() in order to be notified when driver initialization is finished. Only after this method is called should a specific driver implementation rely on all relevant information being present.