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.
Related
I would like to use a windows machine as a USB488/USBTMC device. USB488/USBTMC is a reimplementation of the good old GPIB/IEEE-488 on USB rails. But most articles on the topic refer to a Windows machine as a host/controller. The Windows USB stack is not well suited for USB device/USB OTG modes. However, if you look at some of the high-end gear like oscilloscopes and spectrum/network analyzers, it is well known that they are often Windows machines inside with some additional hardware. So, how it is done?
To some background: it is a project to retrofit a very old SEM microscope with new hardware. The current one is a 68k custom system with a CRT that uses a GPIB interface for comm with a PC. Things like sample spectroscopy are done as a BASIC program running on a pc and communicating through that gpib port. The plan is to replace that 68k junk with a modern day windows pc with an FPGA on a PCIe bus. For compatibility reasons, it would be nice to have a usb488 port in the new PC. Though I have no idea of how to do it properly. The only solution I have so far is to have some cheap USB-capable micro hanging on the SPI bus on the FPGA facing side and a USBTDM class on the USB side. But maybe Im missing something and there is a specific thing or chip that exists that can do it that Im not aware of.
I can only speculate how high-end oscilloscopes achieve it. The most likely option is that they use a dedicated chip like a MAX3420E. It is connected via SPI. Part of the USB protocol is implemented by the chip, part of it will be implemented by the oscilloscope software.
Most USB controllers chips found in PCs can operate as the host only. And even if they could do a role swap, Windows (for Desktop) has not supported device/peripheral mode until recently. It now does. See USB Dual Role Driver Stack Architecture. But I don't fully understand it to tell you what hardware you would need to purchase where this feature is enabled.
Role swapping is very common on smartphones. It is also implemented in Linux (search for "Linux USB gadget"). Many Apple Macs can run in Target Disk Mode, which is a USB device/peripheral mode as well.
In ESXi console I can see my device with lsusb list
And in vm settings I add new USB Device and select my usb from dropdown list, and save settings.
But after that, I could neither see my device in windows server nor in vm configuration!
And when I try to add new device it doesn't show up in dropdown list anymore.
But still can see my device in lsusb list.
This is because the device in question is a USB storage device, specifically a flash drive. A quick Google has this hit: "S102 Pro Advanced USB 3.2 Flash Drive | Buy Now". AFAIK there is no workaround. Gory details follow in the next paragraph. Peruse at your own risk.
In vSphere ESXi 6.5 and earlier releases of ESXi the USB driver stack was a "vmklinux" driver stack with individual drivers for each device type, including USB host controllers. Thus if your installation was on a SCSI disk or PXE booted over the network you didn't need the USB storage driver at all and you could unload it and then pass the device through to a VM. Unloading the driver wasn't offically supported but could be done at the esxcli command line or if you wanted to be really daring you could delete it from your bootbank image. Note that "deleting" was only theoretical as you would really be replacing the driver module with a file of size 0 in the last loaded tar image (the only one that is customer configurable) and could thus be undone, but I digress.
The new USB native driver stack that debuted in vSphere ESXi 6.7 is a monolithic driver which means that it is not possible to unload only the storage driver. You could unload or clobber the entire USB stack but then you'd lose the keyboard and perhaps other things plus the ability to pass any USB device through to a VM. The disadvantages of monolithic USB drivers are well known and are the reason that Linus himself got involved in the redesign of the long gone Linux monolithic USB driver from over a decade ago, but I again digress. As to why VMware "improved" things by replacing a USB stack with half a dozen or more USB drivers with a monolithic stack with all the attendant disadvantages, you'd have to ask them. Feel free to request that they break the driver up into constituent modules as they know how to do this.
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.
Hi we are a embedded development company (www.emfocus.co.in) and new to driver signing details.currently we are developing a driver for a UPS is just a generic USB HID class device.The device firmware has been written in such a way that the UPS will be enumerated as a Human Interface device
But our intention is to treat our UPS as a HID UPS Battery - a battery class device, instead of a generic HID device. So that when we connect our UPS to the Windows, Windows will detect the UPS as a battery connected to the system and the Windows power manager will communicate to the UPS through HID interface. The HID interface here I mentioned in the driver is not just a generic interface. Its HID Power Device Interface. We defined HID Power Device report descriptor in our mini driver, so that the Windows will enumerate a Top Level Collection which is the HID UPS battery for our UPS. That HID UPS Battery top level collection has been implemented in our mini driver. Actually we can use the Windows InBox driver if we have written the device firmware in such a way that it will enumerate a battery top level collection. But our device firmware is written to enumerate as a generic HID device.
Once the HID UPS Battery has been detected by the Windows, the Windows itself starts sending Feature Report requests for getting Battery Capacity, RunTimeToEmpty, AC Present, Charging status... every thing is working fine.
While those requests are issued to our driver, our driver will communicate to the UPS over USB (with its proprietary protocol) and get the status parameters from the UPS and the driver finishes the IOCTL_HID_GET_FEATURE request with the required values in the feature report and Windows Power Manager displays the status on the Power meter.
So that the UPS battery status will be monitored on the Windows Power Meter itself, since Windows considers our UPS as a HID UPS Battery and not a generic HID device after installing our driver.
We want to have the Windows select our driver inf file at all times while looking for best matching driver files.
So to achieve this we want to know if its ok to sign our driver with our code signing certificate or to get the driver WHQL certified ?
If you are just looking to get your device "installable" on an end users system without warnings or signing errors you can create catalog files for the INF installation and sign them with your code signing certificate. The downside to this is that you have to distribute and install the certificate to your users' machines as a trusted publisher before trying to install the device through it's INF.
Alternatively running through the WHQL HCK tests will require that you acquire test logs (for each OS) and submit them to Microsoft for a fee to review and provide a WHQL signature on CAT files created through the HCK submission process. This route is the cleanest for the user because it requires no certificate distribution and also proves that your device passes the WHQL HCK tests.
So the answer depends on what you are trying to do and who your target audience is. I would opt for the WHQL route if you can afford it, as it provides the most benefit for the end users.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.