SEARCH   
Home About Us Products Manufacturing Services Support ARK online Contact Us
Support > Software Downloads >
ARK® Tutorial



Introduction  |  Core Component  |  Communications  |  Additional Topics  |  Reference Guide



The ARK Data Flow

Gennum's hybrid modules can be thought of as containing two types of memory: EEPROM, which is non-volatile (not erased when the hybrid is powered down by removing the battery from the hearing instrument), and registers, which are volatile (erased when the hybrid is powered down). Registers typically contain the active settings of the device and are loaded from EEPROM when the device is powered up or when the user selects a different configuration. These configurations are usually referred to by the locations in EEPROM where they are stored, such as memory A, memory B, and so on. In addition to storing configurations, EEPROM is also used to store control data that is used by both the hardware and software. Control data includes the calibration values that are determined during Gennum's electrical test and Cal/Config at the HI manufacturer, and also such information as the hybrid's model number and serial number. EEPROM also usually has room left over called "scratch area", which the HI manufacturer can use as desired.

As stated in the ARK White Paper, controller components contain the information necessary to communicate with hearing instrument controllers through programming boxes such as HiPro and Microcard. Controller components do not know the details of the individual parameters such as what they are and where they are stored. This functionality, called "parameter mapping" is the function of the product component. Parameter mapping is a relatively simple process for analog products where there are a limited number of parameters, and the controller manages eight to ten potentiometers and switches. Conversely, a parameter map for a PARAGON DIGITAL hybrid could have thirty to forty parameters mapped onto two hundred hardware parameters, organized into multiple sets of addresses and data.

The ARK objects that are used to pass data between product components and controller components are called Memory objects. These objects can contain either the data to be written to the controller or the list of addresses that the controller component must read from. These objects are passed back and forth between the controller component and product component as configurations are read from and written to the hearing instrument.

In analog products, a single configuration contains less than fifty bits of data, so when reading and writing from EEPROM it is feasible to read or write the entire configuration at once. With PARAGON, a single configuration could be as much as 8k bits in size, which can take multiple seconds to read or write with the HiPro. To improve performance when writing to the hybrid, the PARAGON-based product components can generate a Memory object with only the changes that have been made since a previous Memory object was generated. Fast writes are necessary during the fine tuning of a hearing instrument. During the PARAGON read process, the application obtains a Memory object from the product component containing all of the addresses relevant to the configuration, then passes this object to the controller component method that actually performs the read operation. Once the operation is complete, the Memory object, which now contains the configuration data that was read, is passed back to the product component so that the configuration data can be mapped onto the parameters. The information that is passed back and forth in the Memory object during the read process is illustrated in Figure 1.


Figure 1: The Read Process

Communications and Parameter Mapping

This functionality is implemented in the Programmer class in the controller component which exposes a standard interface called IProgrammer2. IProgrammer2 is an extended version of the ARK 1 IProgrammer interface. Using this standard interface and the Programmers collection that is part of the Core Component (as discussed in the previous section), an application can populate a drop-down list box with the list of installed controller components, allow the user to select a programming box from the list and then programmatically access the programming box via the standard IProgrammer properties and methods, regardless of which programming box was selected.

This section assumes that the reader is familiar with how controller chips work, i.e, what a read does, and the difference between write and burn. Detailed information on controller chips is available in Gennum's application notes. This tutorial focuses on the standard interfaces that apply to any supported controller chip or programming box and uses the Params example source code to demonstrate a possible implementation. A full listing and description of the IProgrammer2 properties and methods is given in the reference guide.

The Open and Close Methods
The Open and Close methods are responsible for initiating and terminating communications between the PC and the programming box. Open must be called before any other programming box methods are called, and Close should be called before the program exits. The following code segment from the Params example illustrates the usage of these two methods. 
Private Sub cmdOpen_Click()
    On Error GoTo HandleError
    MousePointer = vbHourglass
    m_Prog.Open hWnd
    UpdateState OP_OPEN
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    UpdateState OP_CLOSE
    MousePointer = vbNormal
End Sub
Private Sub cmdClose_Click()
    On Error GoTo HandleError
    MousePointer = vbHourglass
    m_Prog.Close
    UpdateState OP_CLOSE
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    MousePointer = vbNormal
End Sub
The line 
m_Prog.Open hWnd
causes the controller component to attempt to open and setup the programming box. It is necessary to pass the window handle (hWnd) of the main form of the application, as this is used by the underlying programming box DLLs. UpdateState is an internal subroutine that makes sure that only the appropriate controls are enabled depending on whether the programming box is open, whether the controller has been identified using WhichChip, and whether the part has been initialized using Init or Timing.

The line 
m_Prog.Close
releases the programming box and allows it to be used by other applications. Close should also be called in the Form_Unload subroutine (or equivalent), as shown below. 
Private Sub Form_Unload(Cancel As Integer)
    If Not m_Prog Is Nothing Then m_Prog.Close
    ' Other de-initialization tasks
.
.
.
End Sub
The manufacturers of programming boxes may also recommend that fitting software developers release control over the programming box when the application is minimized.

The WhichChip Method
The WhichChip method causes the programming box to read the preamble from the connected controller and identify it, as long as it is supported. WhichChip takes one or two arguments. The first argument is the ear port to which the device is connected. This can be specified with the constants fLeft or fRight or the numbers 0 or 1, representing the left and right ears, respectively. The second argument, which is optional in Visual Basic, overrides the controller detection and forces the component to set the controller to the one specified. If the specified controller is not supported, an exception occurs. If the connected controller is not the one specified, an exception will occur when Init or Timing (see below) are called.

WhichChip returns the ControllerInfo object for the detected or specified controller. Here is an example: 
Private Sub cmdWhichChip_Click()
    Dim i As Integer
    Dim info As ARK.ControllerInfo
    Dim mem As ARK.IMemory
    On Error GoTo HandleError
    MousePointer = vbHourglass
    Set info = m_Prog.WhichChip(fLeft)
    m_DetectedController = info.Name
    m_FirstAudioMemory = -1
    m_ControlMemory = -1
    For i = 0 To info.MemoryCount - 1
        Set mem = m_Prog.GetEmpty(fLeft, i)
        If mem.Type = fResistor And m_FirstAudioMemory < 0 Then
            m_FirstAudioMemory = i
        ElseIf mem.Type = fControl Then
            m_ControlMemory = i
        End If
    Next i
    lblStatus.Caption = "WhichChip detected a " + m_DetectedController + "."
    UpdateState OP_WHICHCHIP
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    UpdateState OP_OPEN
    MousePointer = vbNormal
End Sub
This subroutine also iterates through all of the memories in the controller and determines which memory is the first audiological memory (usually this is 0) and which is the control memory. GetEmpty is used to obtain a memory of the correct type for the given memory number, and the type is then checked. GetEmpty is discussed in detail in the next section.

Memory Objects
Memory objects, accessed through the IMemory2 interface, are often passed back and forth between ARK methods and properties, as was discussed in the section entitled "The ARK Data Flow". The properties and methods of IMemory2 are fully described in the reference guide and are summarized below.

ControllerInfo The ControllerInfo object for the controller that the memory corresponds to (read-only).
Type The type of memory (read-only).
Parameters The collection of controller parameters that are stored in the particular Memory object.
Requests When reading, the collection of addresses to be read from and the data that was read. When writing or burning, the collection of addresses and data to be written. New in ARK 2.
Copy Makes a copy of the memory object (method). New in ARK 2.


The Type property in the IMemory2 interface returns a number representing one of the following constants:

fResistor The memory contains configuration data that affects the audiological behaviour of the hearing instrument.
fControl The memory contains calibration and control data that is read when the device is initialized.
fStorage The memory contains general purpose storage data that is not usually read when the device is initialized, but might be shared between Gennum's electrical test and the manufacturer's Cal/Config.
fScratch (PARAGON only) The memory is available for use by the manufacturer.

The Parameters collection contains a number of Parameter objects, accessed through the IParameter2 interface. These parameters are not specific to an individual product component; they apply to all products that use the same controller chip. For programmable analog controllers, these parameters represent the programmable resistors and switches in the controller chip, and contain all of the configuration data. For the GC5050 controller chip used in PARAGON DIGITAL hybrids, some of the configuration data is passed in the Parameters collection but most is managed in the Requests collection which is discussed later in this section. The only parameter that is present in fResistor type memories for the GC5050 is the Valid parameter which indicates whether the memory contains valid data.

Parameter objects have a number of properties, including the parameter name, type, value, and the possible range of values. Parameter values are always long integers, but are often indexes into lookup tables of double or string values. These lookup tables are stored in the List property or TextList property, depending on the parameter's type. The complete list of properties for Parameter objects can be found in the reference guide.

The Type property in the IParameter interface returns a number representing one of the following constants:
fSingleBit The parameter is boolean, either on (1) or off (0), or true (1) or false (0).
fList The parameter value is an index into a lookup table of double precision floating point values. A suitable control allowing the end user to adjust this parameter might be a slider or dial.
fTextList The parameter value is an index into a lookup table of strings. The items in this table are usually an ordered list that could not be stored as numbers such as "1/12", "1/6", "1/4", "1/3". The same control used with an fList parameter would be used with an fTextList parameter.
fDiscrete The parameter value is an index into a lookup table of strings. The items in this table are discrete choices such as "one-mic omni", "two-mic omni", "directional". These values could be populated into a drop-down list box from which the user could choose one.
fData The parameter contains arbitrary data.


The Requests collection is new in ARK 2 and is accessed via the IRequests interface. Requests collections are completely managed by PARAGON-based product components and do not need to be manipulated by end-user applications. They contain product-specific configuration data as sets of addresses and arrays of bytes. The Requests collection is always empty for programmable analog controllers.

Product Component Parameters
Product components also have two Parameters collections which contain objects of the same type stored in the Parameters collection in Memory objects. These two collections can be obtained via the IntParameters and ExtParameters properties of the IProduct2 interface. The parameters in the IntParameters collection relate to the audiological behaviour of the hearing instrument caused by the hybrid and the parameters in the ExtParameters collection relate to audiological effects caused by external components. In some of the analog product components, an external volume control parameter was available in the ExtParameters collection, but it is no longer used in PARAGON-based product components. When this document refers to product component parameters, it is referring to the parameters in the IntParameters collection.

The following code segment is the UpdateParameterList subroutine from the Params example source code. This subroutine looks at the set of product component parameters and updates the list box with the current parameter values. 

Private Sub UpdateParameterList()
    Dim i As Integer
    lstParameters.Clear
    For i = 0 To m_ParamList.Count - 1
        lstParameters.AddItem m_ParamList(i).Name & "=" & m_ParamList(i).Value
        lstParameters.ItemData(lstParameters.NewIndex) = i
    Next i
End Sub
The next subroutine responds when the user selects a parameter from the list.
Private Sub lstParameters_Click()
    With lstParameters
        Set m_Param = m_ParamList(.ItemData(.ListIndex))
    End With
    lblParameter.Caption = m_Param.Name
    txtValue.Text = CStr(m_Param.Value)
    lblRange.Caption = m_Param.Min & " to " & m_Param.Max
End Sub
Then, when a user clicks the Set button to change the value of a parameter, the following event is triggered.
Private Sub cmdSet_Click()
    Dim x As Long
    Dim idx As Integer
    On Error GoTo BadValue
    x = CLng(txtValue.Text)
    If x < m_Param.Min Or x > m_Param.Max Then
        MsgBox "The value is out of range.", vbOKOnly, "Bad Value"
    Else
        m_Param.Value = x
        ' Save the currently selected parameter
        idx = lstParameters.ListIndex
        UpdateParameterList
        ' Restore the parameter selection
        lstParameters.ListIndex = idx
    End If
    Exit Sub
BadValue:
    MsgBox "The value must be an integer.", vbOKOnly, "Bad Value"
End Sub


The GetEmpty Method
The GetEmpty method in IProgrammer2 returns a new Memory object for the specified ear and memory number. Because this Memory object was created by the controller component, it knows nothing about product-specific configuration data and hence has an empty Requests collection. Memory objects created by GetEmpty are useful for seeing what type a certain memory number is, and what parameters are available. This is what GetEmpty was used for in the cmdWhichChip_Click example method above.

The GetFull Method
GetFull is a new method in ARK 2 that is part of the IProduct2 interface, the key interface to product components. This method returns a new Memory object of a given type (fResistor, fControl, fStorage, or fScratch), with the Requests collection set up with all of the addresses needed for a Read operation. This method is part of the product component interface because PARAGON-based product components know where the relevant data for a given type of memory is stored in EEPROM. For programmable analog products, GetFull returns the same Memory object that would be returned by GetEmpty, because these products do not use the Requests collection.

The InitEx and Timing Methods
Once the hybrid has been identified with WhichChip, it must be initialized. Both InitEx and Timing return the timing measurement that the methods perform. The difference between the two methods is that InitEx also reads the control word, which is necessary for initial communication with controllers such as the ER102, and necessary with PARAGON-based product components to obtain the required calibration and control data.

InitEx differs only from the ARK 1 Init method in that the control parameter is an [in, out] parameter instead of an [out] parameter. [in, out] indicates that the Memory object is passed to the method, is modified, and then returned by the method. [out] indicates that the Memory is created by the method and then returned. In the ARK 1 Init, the latter was possible because the controller component only had to call GetEmpty to create a new Memory object and then return it. In ARK 2, GetFull must be used to create the Memory object, so the controller component cannot do this itself. Thus, before InitEx can be called, a new Memory object must be obtained from the product component as shown in the example below. 
Private Sub cmdInit_Click()
    Dim timing As Long
    On Error GoTo HandleError
    MousePointer = vbHourglass
    ' Make sure that the controller associated with the current
    ' product is the same as the controller that was detected.
    If Not m_Prod.ControllerInfo.Name = m_DetectedController Then
        MsgBox "You must select a product corresponding to the connected " _
        + "device before it can be initialized.", vbOKOnly, "Error"
    Else
        ' In ARK 2, it is recommended that InitEx be used instead
        ' of Init.  With InitEx, the control word parameter is an
        ' [in, out] parameter instead of an [out] parameter.
        ' The reason for this is that the control word memory object
        ' should be obtained from the product component via GetFull,
        ' so that InitEx can know what control data the product
        ' component needs and then obtain that data.
        Set m_Control = m_Prod.GetFull(fControl)
        timing = m_Prog.InitEx(fLeft, m_Control)
        If m_DetectedController = "GP523" Then
            Select Case m_Control!HybridCode
            Case 1
                lblStatus.Caption = "Init detected a GA3204."
            Case 2
                lblStatus.Caption = "Init detected a GA3205."
            Case 3
                lblStatus.Caption = "Init detected a GA3206."
            Case 4
                lblStatus.Caption = "Init detected a GA3203."
            Case Else
                lblStatus.Caption = "WhichChip detected a GP523."
            End Select
        ElseIf m_DetectedController = "GC5050" Then
            Select Case m_Control!HybridID
            Case 1
                lblStatus.Caption = "Init detected a GB3210."
            Case 4
                lblStatus.Caption = "Init detected a GA3209."
            Case Else
                lblStatus.Caption = "WhichChip detected a GC5050."
            End Select
        End If
        ' The control word is now passed back to the product component so
        ' that it can complete its initialization.
        m_Prod.SetControllerMemoryEx m_Control
        UpdateState OP_INIT
        Set m_LastWritten = Nothing
        Set m_LastBurned = Nothing
    End If
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    UpdateState OP_WHICHCHIP
    MousePointer = vbNormal
End Sub
For analog products, calling GetFull followed by InitEx has the same behaviour as calling Init alone. The above example also looks at the hybrid ID in the control memory's parameters to determine which hybrid was detected.

GetControllerMemoryEx and SetControllerMemoryEx
In ARK 2, GetControllerMemoryEx and SetControllerMemoryEx are the product component methods that perform the parameter mapping function. GetControllerMemoryEx takes the current state of the parameters in the product component and produces a Memory object that can then be written or burned to the hearing instrument. SetControllerMemoryEx takes a Memory object that might contain data just read from the hearing instrument and updates the current state of the parameters in the product component.

The difference between the new ARK 2 methods and the ARK 1 ControllerMemory property is that GetControllerMemoryEx now supports generating Memory objects that only contain the Requests needed to update the hearing instrument with the incremental changes made with respect to another Memory. SetControllerMemoryEx is identical in function to setting the ControllerMemory property in ARK 1. The new method was just added so that it could have method semantics similar to GetControllerMemoryEx. With analog products, GetControllerMemoryEx and SetControllerMemoryEx behave in the same way as the ARK 1 ControllerMemory property, as incremental writing and burning is not supported or necessary.

The ReadEx Method
The ReadEx method reads a particular memory from the initialized controller attached to the specified ear port. Like InitEx, it differs from Read in that the Memory object is passed as an [in, out] parameter rather than an [out] parameter. This implies that the application must call GetFull on the product component before ReadEx, as shown in the following code segment. 
Private Sub cmdRead_Click()
    Dim mem As ARK.IMemory
    Dim idx As Integer
    On Error GoTo HandleError
    MousePointer = vbHourglass
    ' Ask the product component what configuration data needs to be read.
    Set mem = m_Prod.GetFull(fResistor)
    ' Perform the read.  ReadEx is used instead of Read because we need
    ' to pass mem as an [in, out] parameter rather than an [out] parameter.
    ' This is because we used GetFull to obtain the memory object rather
    ' than letting Read do this for us (which will not work properly with
    ' PARAGON-based product components).
    m_Prog.ReadEx fLeft, m_FirstAudioMemory, mem
    ' Give the data back to the product component
    m_Prod.SetControllerMemoryEx mem
    ' Set the Valid checkbox to the appropriate value
    If mem("Valid").Value Then
        chkValid.Value = vbChecked
    Else
        chkValid.Value = vbUnchecked
    End If
    ' Save the currently selected parameter
    idx = lstParameters.ListIndex
    UpdateParameterList
    ' Restore the parameter selection
    lstParameters.ListIndex = idx
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    MousePointer = vbNormal
End Sub
This example demonstrates the use of the GetFull, ReadEx, and SetControllerMemoryEx methods in a typical application. The Valid flag is handled separately, as this is a parameter in the Memory object and is independent of the product component. If the Valid flag is 1, the Valid checkbox is checked, indicating that the memory is valid.

The Write Method
The Write method writes to the hearing instrument's registers and is non-permanent. The following code segment from Params shows an example of this method in use. 
Private Sub cmdWrite_Click()
    Dim mem As ARK.IMemory
    Dim newref As ARK.IMemory2
    On Error GoTo HandleError
    MousePointer = vbHourglass
    ' Get the changes that have occurred to the configuration data
    ' since m_LastWritten was updated.
    If Not m_LastWritten Is Nothing Then Set newref = m_LastWritten.Copy
    Set mem = m_Prod.GetControllerMemoryEx(fRegisters, fResistor, newref)
    ' Write the changes to the device
    m_Prog.Write fLeft, m_FirstAudioMemory, mem
    ' If this is the first time doing a Write, set up m_LastWritten which
    ' keeps track of the memory that was last written.
    If m_LastWritten Is Nothing Then
        Set m_LastWritten = m_Prod.GetControllerMemoryEx(From, fResistor, Nothing)
    Else
        Set m_LastWritten = newref
    End If
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    MousePointer = vbNormal
End Sub
As shown in the example above, there are three arguments to the GetControllerMemoryEx method. In the above example, fRegisters indicates that the parameters should be mapped to the hearing instrument's registers and will be used with the Write operation. fResistor indicates the current set of audiological parameters are to be mapped, rather than control or storage parameters. m_LastWritten is the Memory object that was last written to the device. If it is not null (or "Nothing" in VB terminology), GetControllerMemoryEx uses this Memory object as a reference, and only adds Requests to the Memory object with what has changed with respect to the reference. The first time cmdWrite_Click is called, m_LastWritten is null, so GetControllerMemoryEx adds the full set of Requests to the Memory object. Then, m_LastWritten is set with a Memory object containing all of the requests for the fROM location. Reference memories are always targetted at the fROM location. When GetControllerMemoryEx is called with a non-null m_LastWritten during subsequent calls to cmdWrite_Click, GetControllerMemoryEx automatically updates m_LastWritten with the new changes.

The Burn Method
The Burn method permanently writes to the EEPROM. It can also be used to simultaneously write to both the registers and permanently to the EEPROM. Below is an example of this method in use. 
Private Sub cmdBurn_Click()
    Dim mem As ARK.IMemory2
    Dim newref As ARK.IMemory2
    Dim changed As Boolean
    On Error GoTo HandleError
    MousePointer = vbHourglass
    ' If the control word has changed, burn it.
    Set newref = m_Control.Copy
    If m_DetectedController = "GC5050" Then
        If newref!ManID <> m_Lib.ManID Or newref!LibraryID <> m_Lib.LibraryID Or _
          newref!ProductID <> cmbProducts.ListIndex Then
            newref!ManID = m_Lib.ManID
            newref!LibraryID = m_Lib.LibraryID
            newref!ProductID = cmbProducts.ListIndex
            changed = True
        Else
            changed = False
        End If
    Else
        changed = False
    End If
    ' First, it's a good idea to see if the control word has changed,
    ' and update that if necessary.
    Set mem = m_Prod.GetControllerMemoryEx(From, fControl, newref)
    If changed Or mem.Requests.Count > 0 Then
        If chkVerifyBurn.Value = vbChecked Then
            m_Prog.Burn fLeft, m_ControlMemory, mem, True
        Else
            m_Prog.Burn fLeft, m_ControlMemory, mem, False
        End If
        Set m_Control = newref
    End If
    ' Next, get the configuration data from the product component.
    ' Use location fROMandRegisters if the memory is valid so that
    ' the configuration takes effect.  Otherwise, just write the data
    ' directly to fROM.  (In analog product components the
    ' locations all have the same effect.)
    ' As is done in cmdWrite_Click, only the changes are written to the device.
    ' (m_LastWritten is used as the reference point.)
    Set newref = Nothing
    If Not m_LastBurned Is Nothing Then Set newref = m_LastBurned.Copy
    If chkValid.Value = vbChecked Then
        Set mem = m_Prod.GetControllerMemoryEx(fROMandRegisters, fResistor, newref)
        mem!Valid = 1
    Else
        Set mem = m_Prod.GetControllerMemoryEx(From, fResistor, newref)
        mem!Valid = 0
    End If
    ' Perform the burn operation
    If chkVerifyBurn.Value = vbChecked Then
        m_Prog.Burn fLeft, m_FirstAudioMemory, mem, True
    Else
        m_Prog.Burn fLeft, m_FirstAudioMemory, mem, False
    End If
    ' If this is the first time doing a Burn, set up m_LastBurned which
    ' keeps track of the memory that was last burned.
    If m_LastBurned Is Nothing Then
        Set m_LastBurned = m_Prod.GetControllerMemoryEx(From, fResistor, Nothing)
    Else
        Set m_LastBurned = newref
    End If
    ' Also update m_LastWritten, as the registers have also been updated.
    Set m_LastWritten = m_LastBurned.Copy
    MousePointer = vbNormal
    Exit Sub
HandleError:
    MsgBox Err.Description, vbOKOnly Or vbExclamation, "Error"
    MousePointer = vbNormal
End Sub
There are a few interesting differences between implementing Write and Burn operations. In a Burn operation, if the memory is valid, configuration data should be written to both EEPROM and registers so that the changes immediately take effect. If the memory is invalid, the configuration data should just be written to EEPROM so that it is available the next time the memory is read. When burning, it is also recommended that the application see if any changes have been made to the control data by the product component, and burn these changes in. For PARAGON hybrids, the ManID, LibraryID, and ProductID are updated if a different product component is being burned in than was detected when the device was first initialized. These parameters are discussed in further detail in the section entitled "ManIDs, LibraryIDs, and ProductIDs".

Non-Standard Functionality
Although the standard interface to controller components is IProgrammer2, it is possible for controller component developers to expose non-standard interfaces from their Programmer class implementations, in addition to IProgrammer2. To use a non-standard interface in Visual Basic, it is first necessary to reference the type library for the controller component in the same way as was done for the Core Component in the section entitled "Using the Core Component". Referencing the type library is necessary for Visual Basic to be able to recognize the non-standard interface, which is compiled into the controller component DLL itself.

The Programmer class implementation in the Standard HiPro Component, provided by Gennum, contains a non-standard interface called IGenHiPro that provides the SetPin5Voltage method in addition to the standard IProgrammer properties and methods. To access IGenHiPro, the type library compiled into GenHiPro.dll must first be referenced. The type library in the Project->References... dialog box is called "Standard HiPro Component 1.0 Type Library". Once this type library is selected, the IGenHiPro interface can be obtained by setting a reference to the non-standard interface with the IProgrammer reference as shown in the following code example. 
Private Sub SetPin5Voltage(voltage As Double)
    ' The library name is GenHiPro of the Standard HiPro
    ' component and the name of the non-standard interface is
    ' IGenHiPro.
    Dim nonstd As GenHiPro.IGenHiPro
    Dim v As Integer
    v = (voltage + 3.5) * 128 / 3.5
    Set nonstd = m_prg
    nonstd.SetPin5Voltage v
End Sub


NEXT: Additional Topics


© ON Semiconductor  |   PRIVACY POLICY  |   TERMS OF USE