I’m developing an application running on Atmel UC3, which has an USB-Controller. My device implements a USB device. The customer may connect the device to a computer for configuration and diagnostics.
I use the ASF (Atmel Software Framework) to implement a USB CDC. If the device is plugged in, Windows assigns a COM-Port to it, and I can successfully communicate, means I can open a Terminal, connect to the COMx Port, and send / receive data.
Now I’m planing a custom Application, which is used as the Interface to the device, and I’m wondering about how I can identify the “correct” COMx Port.
My prefered solution would be to remove all the COMx stuff, and just open the device (using Device-Interfaces), so no “COMx” port will be created, but my Application is able to read / write to the device.
Does this mean, that this is no CDC device anymore? Do I need to write my own driver for that? This is something which is not needed by now. I only have to provide an .inf, which uses usbser.sys as a driver.
Another solution would be to keep using COMx, but to use SetupAPI to look up the Device-Tree for my VID/PID device, and somehow (?) get the ‘x’ in COMx from Windows. This would also be ok, and I think this is much less work, because there is nothing to change in the firmware, and I don’t need to write a custom driver.
Now I’m planing a custom Application, which is used as the Interface to the device, and I’m wondering about how I can identify the “correct” COMx Port.
Take a peek in the registry at HKLM\HARDWARE\DEVICEMAP\SERIALCOMM.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
thank you. By using the registry, I can perform the lookup needed. My final solution is to query hklm.…\currentcontrolset\enum\usb using vid & pid, and use the “PortNumber” value.
But I still need an .inf, giving all the troubles with signing. What do you think of this:
I could even register a device interface guid. So the Application may use a generic bulk IN and OUT endpoint, so I could skip all the COM stuff completely, and even dont need and inf. I maybe use https://developer.chrome.com/apps/usb for the client, since most management is done online, and the usb functionality could be integrated with a chrome plugin.
Do you (or anybody else) have any experience in this?
Anybody knows how I get the required descriptor(s) into an Atmel UC3, by using the Atmel Software Framework?
This is a point worth emphasizing. The serial paradigm can be made to work, if you are forced to interface with existing legacy applications that can’t be changed. But if you have the flexibility of modifying the application or providing an interface DLL, it is easier, more flexible, and more deterministic to use WinUSB to talk directly to the endpoints. Forget about trying to emulate a 50-year-old interface.