![]() |
IDTech Windows SDK Guide
3.2.4.393
API reference for Visual Studio .Net
|
The purpose of the SDK is to execute API commands and process the responses. While an API command such as getFirmware may seem straight forward in execution, the SDK needs to decide on the proper protocol depending on the device (IDG, NGA, ITP) to properly wrap the command, then it must prepare the data for the proper interface. A serial interface is unaltered command data, but if the interface is USB-HID, it can be two different type of HID report packets. If it is USB-KB, then it must execute 8-byte GetFeature/SetFeature packets.
It may be desired to leverage the SDK to communicate with devices not directly attached to the SDK. Examples of this would be for a company to connect to the device using their own SDK, or if the device is attached to an iOS or Android device through Xamarin.
This can be accomplished by configuring the SDK for Virtual Device Operation. You accomplish this be implementing a callback that will receive all the data that SDK wants to send to the device, and then any data that is received from the device you send back to the SDK. We are basically putting a hook in the SDK and diverting the data that would have normally gone to its COM or USB ports.
Request the SDK to open a virtual device, specifying the virtual device type, the connection type, and the virtual write callback
if "comm" does not come back null, the virtual device is initialized. This "comm" instance of IDTechComm will be needed to send device responses back into the SDK.
The SDK will construct the command and deliver it to the virtualWriteDelegate
Take that commands and direct it to a connected device (Xamarin->Android, Xamarin-iOS or other destination)
The SDK supports the following interface types for Virtual Devices
Please note, the Device Type should accurately reflect the type of device being communicated with, but the Interface Type indicates how data will be provided and expected in return.
If DEVICE_INTERFACE_SERIAL is selected, all commands are complete command packets in their proper protcol wrapping, no additional modification are made. The response is expected to be the same.
If DEVICE_INTERFACE_USB is selected, the commands are further processed into USB Reports. These are 64 or 65 byte report format (when USB-HID), or 8 or 9 byte report format when USB-KB. Data is provided in the raw format the device will understand. It is expected the data will be sent through a communication bridge that is just acting as pass through mode.
Example: if you were to execute getFirmware to a virtual device that was defined as serial, a Kiosk IV, which is an IDG Device, will produce the command wrapped in IDG protocol with no additional data:
The Kiosk IV will respond back with an IDG packet, which needs to be sent to the virtualRead method in the SDk for processing
if you were to execute getFirmware to a virtual device that was defined as USB, a Kiosk IV, which is an IDG Device, will produce the command wrapped in IDG protocol in a USB-HID report format:
The Kiosk IV will respond back with an IDG packet in USB-HID report format, which needs to be sent to the virtualRead method in the SDk for processing
In both cases, there is no need to decypter/process what is being sent/received. The SDK will do all appropriate processing with the raw data being provided.