I'm using USB Class02/SubClass02 on my embedded device to make use of the Windows10 build in USB COM port drivers (usbser.sys / mdmcpq.inf).
My device provides manufacturer/device descriptors, but i have found that Win10 does not seem to use them as a title for the device in device manager and in other locations. Instead its just listed as a "USB Serial Device (COM?)" and the manufacturer as being Microsoft.
Does anyone know if there is a way of the device (via flags or similar) instructing Win10 (and drivers) to use the device provided names instead?
Or is the only way to do this by providing a INF only device driver with the strings?
Thankyou.
Or is the only way to do this by providing a INF only device driver with the strings?
Windows uses the INF file for the device title only. Thus you would have to supply an INF file.
Related
What is the additional advantage of developing a full UMDF windows driver if a CDC device is detected as a virtual COM port?.
I have some experience with embedded examples using a microcontroller, both communicating with a terminal like teraterm or using a dedicated USB peripheral that allows for cdc or hid functionality.
Are these drivers the ones you download and install before using any USB device? It is not clear yet what features are avaialble through the host driver.
Often on Windows the "driver" for a USB serial device is no more than an inf file that maps the device VID/PID to the Microsoft usbser.sys CDC/ACM driver.
Recent releases of Windows 10 appear to have stopped insisting that each CDC/ACM have a VID/PID specific inf file, and will load the standard driver for any device that presents as a CDC/ACM device.
The advantage of having a VID/PID specific inf file is that your device can have a vendor specific "friendly name" which can be used in applications to more easily identify your device, rather than just appearing as a generic "USB Serial Device".
One problem with Microsoft's usbser.sys driver (and Linux and Mac OS are no different) until recently was that if you disconnect the USB device, the driver is unloaded even if an application has the COM port open, and the application must close and reopen the port to recover when reconnected. I have previously used a custom driver (provided by a third party), that does not unload if an application has the port open, so that when the USB cable is reconnected, the data connection continues as normal, just as it would if it were an RS-232 cable. However, again in recent versions of Windows 10 I have noticed that usbser.sys appears to exhibit this behaviour in any case.
Note that when you do provide your own driver file, or even just a custom inf file, you will be required to go through WHQL testing in order for your device to be allowed on Windows 10, or to load without warnings on earlier versions. To do that you will need a USB.org assigned VID, an Extended Validation code-signing certificate, and either the tools and facilities to perform the testing, or pay a test house to perform the testing. That all gets somewhat expensive, and may be prohibitive for low volume, low value or non commercial products.
At one time Microsoft too charged for WHQL processing submissions, but no longer do so. That is however little combination since at the same time they changed to requiring an EV certificate and stopped a deal the used to have for low-cost certificate.
The advantage of WHQL qualification is your driver will be provided by Windows Update.
If you are using a USB serial bridge chip rather than your own USB stack and USB controller, then there is a lower cost solution. These chips can be customised with your own VID/PID and descriptors, and the vendor's existing WHQL can be associated to your device so you get all the advantages of your own driver without the costs. Most vendors will even allow you to use their VID and will assign you a unique PID so you can avoid USB.org fees. I have used this route with both Prolific and FTDI devices; it is by far the most cost effective solution.
When I plug a USB web Camera into a PC via USB, what communications is used? I know each device COULD have its own uniques driver, but it seems as though 99% use a common built in driver now. Where is it spec'd and how do you get a linux embedded device to act like a webcam?
What you're looking for is the USB Video Class and you can download the specification for this and other standard USB device classes here:
http://www.usb.org/developers/docs/devclass_docs/
The Linux USB gadget framework has code to emulate such a device:
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uvc.c
I need to communicate with some custom hardware that will use either a FTDI or Silicon Labs usb to serial driver.
I found a couple examples but they are older and was hoping for a more up to date example. Plus, I have been confused by the new AppleUSBFTDI kernel driver in how that works with the IOKit and other chips like the Silicon Labs part. It would be nice to have one program that doesn’t care which driver is used.
I have already looked at this example:
FTDI Communication with USB device - Objective C
The nature of these drivers and devices is that they are supposed to function as a standard serial port virtually over USB. So in terms of access it should be no different than accessing a standard RS232 COM port.
I would suggest reading the Serial Programming Guide for POSIX Operating Systems. I'm not sure what older examples you're seeing but serial access itself is many years old, but the idea behind communicating to the serial device is the same in the case of these USB to serial bridge devices.
For information on some Objective-C frameworks, take a look at this Stack Overflow post.
Finally, here is an article directly from the Apple documentation, Working With a Serial Device, and you'll see it also references the POSIX style API.
You should simply need to install the driver associated with your device and plug it in for this to work. In terms of the Silicon Labs CP210x device just download and install the OSX driver. Then plug in your device. This is where the one difference may show up, the name of the tty device on the system (it will show up in the /dev directory). In the case of the CP210x it will show up and be accessible as tty.SLAB_USBtoUART or cu.SLAB_USBtoUART. This will be the name of the device you should open, then use and API from above to start your communication.
Quite a while I am struggling with a problem regarding the installation of certain USB device driver in Windows CE 6.0.
The device is some kind of Digital and Analog IO device that connects to the USB port.
It is the LabJack U3.
I followed all instruction and put the driver (labjackusb.dll) and coresponding registry entries into the Windows CE image but the device is not detected correctly.
On every boot up a small Message box came up with the Title "Unidentified USB Device"
and the message "Enter the name of the driver for this USB device:"
Whatever name I put into it want work. I tried the name of the dll. Some title in from the registry and so on but never succedes.
The driver does not work nor the device.
The customer support can not help me so I am asking here somebody to help me at least
with a steps to follow to try to find a solution.
Why the OS does not matches the USB device with the corresponding driver?
I checked everything one million times and everything is in place.
There are a load of reasons this might fail. First:
Is the driver definitely a Windows CE driver?
Is it built for CE 6.0 (not 5.0 or something else)?
Is it built for the same processor architecture you have?
The way to really debug this is to hook up KITL, put in a debug version of device.exe and see what the device managet is actually doing when you plug in the device. A way better and way more reliable mechanism than just trying to guess.
The rest of my team will make for my application a simple non-standard USB microphone, but until they finish it I will have to emulate it, for integration testing purposes.
Is there any risk in a physical loopback? Yes there is
Will a physical loopback work? Only with a USB bridge
There is any way to create a logical loopback? (MSDN has something about this)
There is any general purpose USB emulator software?
In case there is many options available I'd rather work it .NET/Matlab/Python solutions.
Edit: Proof of concept here
I strongly recommend this project, USB IP. It is a way of connecting USB devices over the network. There is a Windows client.
What this means is, you install the client on your Windows computer.
This device then expects to talk to a USB device connected to a Linux computer, the server:
What you now do, is either create a fake device driver for Linux, that looks like is connected to a physical USB device, but in reality is just logic pretending to be your USB device. There are tutorials for writing USB drivers for Linux. Or you create your own stub driver for the Device Control Manager (see picture above). This stub driver could run on Windows or Linux, it wouldn't matter. It could even run on the same Windows machine which is the USB client.
The DSF USB Loopback Device mentioned in the question itself, would be the same kind of solution as a stub driver for the Device Control Manager, but taking Linux out of the picture altogether.
You can write virtual USB device using QEMU.
You can duplicate already existing device, like the dev-serial.c found in this QEMU repository and change it for your needs.
After you write and compile your USB device you can simply attach it to your VM using the QEMU command line interface.