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.
Related
I would like to experiment with real time audio and was wondering what options are there for accessing audio via a usb port?
I would like to get data from this hardware in an audio stream.
Is this sort of thing best handled by audio frameworks or should the data be fetched using IOKit and passed to e.g. an audio component using a framework?
Also, how is this access effected if e.g. A DAW is accessing the audio from the port? Is dual access handled by the OS?
The specs page for that hardware (Moog Minitaur) doesn't claim that it can transmit audio over USB, only that it has USB MIDI- essentially it has a built in MIDI interface.
If you wanted to get audio from it into your computer you would have to connect it to your computer's line or mic input, or an external soundcard - which may itself connect via USB. One way to handle audio in OSX would be Core Audio. You shouldn't need to write any drivers or anything to deal with the low-level I/O with the soundcard, as the soundcard should come with a driver if there isn't one already in the OS.
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.
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.
I am trying to design a Windows KMDF driver for an old USB Webcam.
I think I have enough informations on the driver development / USB protocol side, but I am wondering how I should expose the webcam functionalities from the driver so that Windows program can take advantage of it.
This webcam has 3 functionalities:
a video stream,
an audio stream,
a "take picture" hardware button.
For each of those, what is the more natural way to expose it to Windows, so that my webcam can be used in relevant programs (gTalk, Skype, etc.)? Or, to revert the question: what is expected by those programs, and how do they detect webcams?
When you write a 'WebCam' driver, you should use kernel streaming as your driver model. this provides you with the correct interfaces, so that other programs can communicate with your device through DirectShow/VfW/etc. .
Currently kernel streaming is implemented in the AVStream mini driver base. The WDK contains a AVStream mini driver sample to base your own driver on. The backend to the device can then be implemented using KMDF.
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.