You can create a custom driver for the SmartServer to provide support for additional protocols not built into the standard SmartServer software. To develop a custom driver, you implement your driver-specific code in C or C++ using the GNU C++ compiler (g++) and link your driver with the IAP Driver Library (IDL) that is included with the SmartServer. This page outlines the basic steps required to implement an IDL driver, with specific references to the IDL API. The other pages in this section walk through an example implementation and the sample code in some detail and also include specifics on compiling, running, and debugging an example driver.
The basic architecture for an IDL a custom driver is illustrated in the following flowchart:
Step 1 – Create a New
...
Custom Driver Instance
The first task required by the IDL driver code is to create Create a new IDI instance. This instance is then referenced You will reference this instance throughout the custom driver code. For example, you will reference this instance when initializing the driver , or registering callback functions associated with the instance and so on. For reference refer to the IdlNew() function described in the Init Functions section in the IDL API. The IdlNew() function returns a pointer to the newly created driver instance, which is then referenced when interacting with the IAP Driver LibraryIDL.
Step 2 – Register any Supported Callback Routines with the IAP Driver Library (IDL)
After creating a new driver instance, the driver code needs to register Register any supported callback routines functions with the IAP Driver Library ( IDL). The driver library calls these callback functions as necessary when actions that must be executed by the custom driver code occur. This includes things such as creating a new device that uses this protocol, provisioning / de-provisioning a device, reading & writing data points, and so on. Registering a callback routine with the library requires calling the appropriate callback set function and providing the previously created driver instance as a parameter, as well as a pointer to the custom driver’s routine that is to be executed when the associated event occurs.
...
Step 3 – Start up any Driver Specific Code, IdiStart()
It is good practice before initializing the driver instance to execute a routine to start Start up any driver-specific code that is required for this custom driver instance to operate. For example, your custom driver might need to open and initialize a serial port or a USB interface as well as initialize any driver-specific constructs. The example driver described below implements a stub function that illustrates this activity. As shown in the flowchart, if the custom driver successfully initializes anything it needs to start up, the driver code is then free to create any threads required and to initialize the driver instance itself.
...
Since initializing the IDL driver instance surrenders the execution thread to the IAP Driver LibraryIDL, if a custom driver needs any independent Linux POSIX threads to handle any background processes the driver needs to execute, these threads should be created before calling IdiInit() to start up the custom driver instance. For example, if my driver needed an independent thread to handle incoming, asynchronous protocol packets, I could you can use the Linux POSIX pthread library to create a thread for this purpose:
...
Step 5 – Initialize the Driver Instance
The final task required by a custom IDL driver is the initialize the Iinitialize the driver instance itself that was created in Step 1. Initializing the driver instance involves calling the IdlInit() function and passing a reference to the instance, as well as a configuration file that provides the IAP Driver Library IDL important startup information about your custom driver. Reference code is included in the example IDL driver outlined in the sections that follow. Details concerning the IdlInit() call and the associated parameters is documented in the Init Functions section. In addition, the configuration file passed to the IdlInit() function is documented in Conf File section.
...
The bulk of the code contained within a custom IDL driver will often be found in the callback functions themselves. This is where driver specific code that needs to execute based on activities like provisioning a device , or reading a data point , and so on will be located. The IDL API documentation section contains complete details on these various callback functions and the example IDL driver includes actual reference code that implements these common callback functions. For example, if my your custom driver needs to implement code to handle creating a device, the device create function, the associated callback function, and the required return call are documented together in the Device Create Functions section.
...