I have a USB device that uses the inbox class driver.
How can I write a program to update its FW?
Can I avoid writing a driver by using the WinUSB library?
It doesn't make sense to me that I am using the inbox driver and I will need to write a driver only for the common operation of FW upgrade.
Thanks,
Shai
I have a USB device that uses the inbox class driver.
This class uses HID as base. You could use HID to update the Firmnware too, eliminating the need to provide custom drivers. WinUSB needs at least an inf file.
Related
I've seen two ways to install Windows drivers.
a. Using both SYS file and INF file. (such as NDIS driver)
b. Only use SYS file, the driver will be loaded by a service. (such as drivers in
C:\Windows\System32\drivers)
So, my question is:
1. What kind of drivers or situations require INF a file?
2. What is the root cause of this difference?
There are different kinds of drivers on Windows. Each type of driver has its own story for how the driver is installed. Here are a few common types of drivers.
PNP device driver. A PNP device driver operates a device in the device tree. PNP drivers are loaded by PNP when the device is enumerated by its parent bus. In order for PNP to know which type of device your driver supports (and a bunch of other stuff), you need a PNP-style INF that describes your driver.
SCM-managed driver (sometimes called "legacy driver"). SCM loads these drivers based on the same rules it uses to start NT services. SCM does not require any INF. You can register a new driver with SCM by simply running sc.exe create my_cool_driver type=kernel binPath=c:\my\driver.sys start=auto or calling the CreateService API. But if you already have an INF for other reasons, you can use any style of INF to do the same via the AddService directive.
NDIS lightweight filter (LWF) driver. LWFs are not loaded by NDIS; NDIS doesn't care how they're loaded. Most LWFs choose to be loaded by SCM, since that's easy to control. An NetCfg-style INF is still required, though, since NDIS needs to know what types of network adapters to attach the filter to (Ethernet vs WLAN, for example).
Export driver. An export driver is loaded by the memory manager when Mm is trying to load some other driver that imports functions from it. An export driver is just a kernel equivalent of a DLL — it just provides APIs to other drivers. Export drivers don't need an INF; they just need to be put into the right directory on disk. If you already have an INF for other reasons, you can use the CopyFiles directive to do this.
WinUSB driver. WinUSB is a built-in driver that delegates most of the responsibilities of managing a USB device to usermode APIs, so any application can easily do simple things with the device. This means pretty much any application can be the driver for the device. If the USB device puts certain data in its hardware descriptor, Windows will know to automatically set up WinUSB, so no INF is required. But if the hardware does not advertise that it needs WinUSB, then you'll need a WinUSB-style INF to tell Windows to set up WinUSB for you. Beyond that, you don't need an INF to call WinUSB APIs from your application.
If you're just experimenting and want to call a few kernel APIs for fun, you can choose any type of driver. Most people find that an SCM-managed driver is the easiest, since you don't need any INF and you get full control over when the driver starts and stops. But in any other situation, the choice of driver type is largely dictated by the problem you're trying to solve. For example, if you're writing a driver for a PCI GPU, you must use a PNP driver, and therefore must have a PCI-style INF.
I am creating my own midi-instrument and would like to know how to create a PC driver program for this instrument. Does anyone have any pointers or resources I could look at to help me complete this task?
All i have found so far is
1) https://msdn.microsoft.com/en-us/library/windows/hardware/mt187811(v=vs.85).aspx --> USB drivers
Just make your device conform to the USB MIDI device class specification, and you do not need to write any driver for the PC.
Check out the Driver samples for Windows 10. The Sample KMDF Function Driver for OSR USB-FX2 might be closer to what you need, if you want to write a USB device driver.
I have developed a USB device that communicates with linux over a simple but proprietary interface and some custom Linux drivers. My goal is to port this to Windows without writing windows drivers. What I would like to do is find an open source or inbuilt class driver for windows that would look like a COM port in Windows. Then I would tailor the embedded software to match what ever protocol and descriptors the virtual COM port expects to see.
The idea would be that I could plug my device in to a Windows machine and a relatively high speed COM port would appear with out me having to develop Windows drivers for it.
I have been looking at the USB CDC (Communications Device Class) documentation and it looks promising, but I don't know which sub interface would be best to use so that it would show up as a COM port.
Has anyone here done any work like this before or could provide some insight?
Specifically:
Are there virtual COM drivers "built in" to windows or would I need a 3rd party driver.
Which CDC sub class should I use for simple RS232 emulation (No need for modem AT commands, etc)
Is there a better option to do what I am trying to do.
Thanks
There is a USB-to-serial driver built in to Windows that will do what you want. It is called usbser.sys:
http://support.microsoft.com/kb/837637
You will have to write an INF file and distribute that to your users, but that will not be too hard because it is only a few kilobytes of text and you can find examples online.
I'm not aware of any great documentation for this driver by Microsoft, so my advice would be to find some other device that uses it, such as Pololu Wixel, and copy what they did.
Here are the device descriptors we used and the special control tranfers we had to implement:
https://github.com/pololu/wixel-sdk/blob/master/libraries/src/usb_cdc_acm/usb_cdc_acm.c
You can see our INF file, wixel_serial.inf, by downloading the software and looking in the drivers folder:
http://www.pololu.com/docs/0J46/3.a
(There are other files in there that are not necessary for you.)
You can also look at the Arduino Uno because they use the same driver.
Whatever you do, please don't use our USB Vendor ID in your product! You need to get your own.
Update: In Windows 10, you don't need an INF file anymore because of the new usbser.inf driver that comes with Windows.
If you are using a UART you can easily interface it to a FTDI USB chip like http://www.ftdichip.com/Products/ICs/FT232R.htm or a Prolific like http://www.prolific.com.tw/eng/products.asp?id=59
For development, prototype and testing I have half dozen of these laying around http://www.pololu.com/catalog/product/391
I connect it directly to the UART pins on AVR and 8051 micros.
We are creating small system which has GPS receiver and PC. We want to test my GPS receiver, We do not want to go for a driver on the first go. First I would like to test my circuit works or nor. GPS IC has been set to output NMEA sentence. We want a program which just reads data from USB port and print it on the screen.
Can we write something like this easily ? Do we have any open source tool which will achieve this purpose ?
Platform : Windows 7
All devices need a driver, so I'm going to interpret your question as "how can I read NMEA data from my GPS using only drivers provided by the OS, so I don't have to write my own?"
If the GPS chip has a USB interface, then you should have gotten a driver with it. But most GPS chips have a UART interface which in your case sounds like it is connected to a separate USB-UART conversion chip. That conversion chip most likely came with a driver as well, but if not, you could jumper the reset pin of the converter chip, disabling it, and then attach a TTL/RS-232 level converter (available off-the-shelf) to the UART traces and then to your computer's serial port.
Unless you suspect that the driver for the USB-UART converter is causing problems, I wouldn't bother.
Anything connected via USB is a device. Devices require a device driver, period.
You might be able to get away with an existing driver built into Windows. This is how USB memory keys work for example - they present a generic device that looks like a removable disk, and Windows already includes the drivers for generic removable disks.
You would need to check the documentation for your device to see if it can emulate a device which already has drivers. Otherwise you must install the company's drivers, or you're out of luck.
Have a look at libusb. You should be able to read the data with that and a little code. (Yes, it's a driver. I take the question to mean "without writing a driver".)
You need a device driver for your device. Unless Windows already have a class driver for the device.
For USB devices on Windows 7 you can write a user-mode driver, see UMDF.
I am working on building a USB Video Class camera, which is supposed to work well with various flavours of Windows. The camera needs firmware upgrade support to upload new software images into it. There are two ways to do it, as far as I know.
Use DFU.
Use control endpoint of the UVC Class device to transfer bytes into the device.
To use the second option, it looks like, one needs to write a Filter Driver. Is this correct? Is there any other way to accomplish this task?
There are several ways to do what you want.
The standard UVC Class driver supports a user mode interface, from which you can send USB packets to the device. This interface is called: USB Video Class Extension Units.
Another way is to use WinUSB, where you install the WinUSB driver for your device. After that you can send USB packets through the WinUSB interface.
The most involved solution would be, to write a complete USB driver. Just see the samples in the WDK.