Print version of this Book (PDF file)
Class Hierarchy for User-Contributed Drivers
The diagram in the following figure depicts the relationships of the classes that are of principle interest to a user creating a driver. The arrows without labels indicate pointers held in the objects.
Figure 6 Classes Involved in the HP 4194 Example of a User Driver
At the top of the hierarchy are classes named unit, instr, and instr_options. All instrument drivers in IC-CAP consist of classes derived from these 3 classes. When Agilent Technologies adds a driver to IC-CAP, one new class is derived from instr, one or more new classes are derived from unit, and one new class is derived from instr_options. The process of deriving new classes from these base classes permits the new driver to efficiently reuse generic functionality present in the base classes, while also introducing new code where necessary to accommodate the specialized needs of the new instrument.
The division of a driver into unit, instr, and instr_options components helps modularity. Generally, the role of each of these parts is as follows:
| • | instr - manages operations associated with the whole instrument, such as self-test and initialization. |
| • | instr_options - presents a user interface for and stores the values of options unique to each Setup in which an instrument is used. For example, the option Use User Sweep determines whether an instrument does or does not use its internal sweep capability during measurement in a particular Setup. |
| • | unit - manages operations on a single SMU for example, in the case of a DC analyzer, or on a single oscilloscope input, in the case of a multi-channel digitizing oscilloscope like the 54120 series. Operations undertaken at this level include the application of DC and other signals to the DUT, as well as the acquisition of the measured data. |
Intermediate in the hierarchy are 3 classes named user_unit, user_instr, and user_instr_options. These serve the following purposes:
| • | Hide any virtual functions of unit and instr that are unlikely to be necessary to override in new driver classes. This allows the critical function declarations to be concentrated in one location, with comments close at hand. |
| • | Introduce new member functions provided for Instrument Options management or for convenience. |
At the bottom of the hierarchy are examples of classes introduced by the Driver Generation Scripts. When a user adds a driver to IC-CAP, the Driver Generation Scripts add a class derived from user_instr, one or more classes derived from user_unit, and a class derived from user_instr_options. The class derived from user_instr_options, which is hp4194_table in the example driver, is completely declared and implemented when the user runs the mk_instr_ui script. In other words, a programmer using the Open Measurement Interface need not become involved with any coding that pertains to this user interface component of the driver. The programmer also does not need to provide declarations for any new classes needed for the driver, since these are completely written out when the driver generation scripts mk_unit, mk_instr, and mk_instr_ui are run. However, the programmer is required to fill-in the implementations of several functions that ultimately perform the work done by the driver.