Communicating With Complex HID Device On Windows - Should I Use A DLL?

Hi everyone,

We are in the process of transitioning from an FTDI USB <–> Serial chip to one from Silicon Labs that is HID compliant and therefore requires no drivers. On the mac, we have successfully set up a proof of concept communication with this chip using the MonkeyBread MacHIDMBS class. However, the MBS plugin for windows does not appear to be capable of communicating with this device, as the device requires specific report IDs be both written to and read from in order to set up communication.

So, if none of the above makes any sense - fear not, I’m getting to my question.

The specific chip we are using is the CP2110, detailed here.

SiliconLabs provides some DLLs that can be used to abstract away the HID interaction with this chip, and they provide several examples of how to do so using C# code. Here is one such example:

// HidUart_GetNumDevices [DllImport("SLABHIDtoUART.dll")] public static extern int HidUart_GetNumDevices(ref uint numDevices, ushort vid, ushort pid);

So, here is my question: If I simply include the provided SiliconLabs .dlls with my application distribution (say, by using a CopyFilesStep to copy them into the application library or similar) then can I just use declares to call into them? Will I have to mess with any sort of dll installation, driver signing, or windows certification for these .dlls?

In the past we have used .dlls that were installed as drivers by Windows Update, which worked fine when the drivers correctly installed… but frequently they did not, and our app would fail dismally as a result. We are trying to find a way to communicate with our devices that does not require any sort of Windows Update, driver installation, or certification / signing process for any dll or driver. Ideally, we’d love to just use the existing MBS HID libraries, but until they can support specifying report IDs, that option is unavailable to us on Windows.

Thoughts?

I use DLLs in one of my apps, and there is no need for specific installation. The only requirement is that the DLL expose COM objects for Xojo to be able to call.

Thanks @Michel Bujardet - this is looking more promising.

How can I tell if a DLL exposes COM objects in the right way if I don’t have access to the source?

Thanks!

[quote=164126:@Kimball Larsen]Thanks @Michel Bujardet - this is looking more promising.

How can I tell if a DLL exposes COM objects in the right way if I don’t have access to the source?[/quote]

What I applied is here : http://www.xojo.com/blog/en/2014/01/accessing-net-code-from-xojo.php

I would start by calling the classes described in the Silicon Labs DLL and see if it works.

If it did not, there still may be a way : create a VB DLL that acts as a middle man, calling into the Silicon Labs DLL and allow Xojo to access its own methods which expose COM objects. My own ap uses a VB DLL I wrote to bring functions Xojo does not have (saving indexed color BMP), using the very same technique as the blog does.

For WinHIDMBS class. The report ID is first byte of data block, so you can change it.

Unfortunately, this only applies when sending messages to the device. The WinHIDMBS class does not seem to have any way to specify which message you would like to read.

[quote=164100:@Kimball Larsen]
So, here is my question: If I simply include the provided SiliconLabs .dlls with my application distribution (say, by using a CopyFilesStep to copy them into the application library or similar) then can I just use declares to call into them? [/quote]
That should work as long as they are soft declares
Not 100% sure about what library path to use though

let’s see if we can modify the plugin…