Receiving data from a USB device in C or C++

Question

I need a list of all plugged in USB devices and have the user select one to let the console application receive any data the USB device sends.

I can then start playing a

Answer 1

I simply need a list of all plugged in USB devices and have the user select one to let the console application receive any data the USB device sends.

Getting the list isn't the big problem, it's receiving the data.

I know you don't want to write a driver, but this is what drivers do: receive data from a device.

Answer 2

Here's something to get you started:

• Universal Serial Bus Revision 3.2 Specification - it's a bit long, but a good read if you want to get into USB. It explains everything about how USB works.
• The USB section at MSDN

And for crying out loud update to an OS that's not from the last millenium. I hear Linux has great support for USB.

Answer 3

How can one write a program for USB, wanting to understand the background of it, while not wanting to read much about it, not wanting to use a library, all in the same time? Anyway. there is a project "libUSB Win32" from Stefan Meyer not under heavy development at the moment, but written in C maybe this could be something for you, it has also the ability to run under ancient windows versions ;) you can find it here:
http://sourceforge.net/apps/trac/libusb-win32/wiki
a while ago i have written this in VB6 that makes use of "libUSB Win32" don't know if it can be useful for you:
http://www.activevb.de/cgi-bin/upload/download.pl?id=3061

Answer 4

The advice you're getting here is on the mark; USB is not easy, believe me... I'm working on a USB project but from the back-end. Seems to me that you need to be looking at the back-end too, that's where you really don't have to deal with libraries and all that, but you won't be able to get around the reading whatever you do.

Don't get discouraged yet, but you do need to wet you feet before you jump in and drown. USB2.0 and USB3.0 are quite dry, but I found OSDev Wiki and usbmadesimple to be useful stepping stones.

If you still need to be in the PC, then you should consider trying to get a hold of some open source usb code for maybe a USB sniffer if you can find it.

Answer 5

This is a very persistent question in forums and programming Q+A sites. Never with a happy ending. The B in USB means bus. That is a term in computer hardware design to describe an electrical interface for electronic devices to exchange data. It plays the exact same role as, say, the PCI (express) bus inside your machine. Since it is an electrical specification first and foremost, USB supports a very large number of types of devices. Anything from a wireless network adapter, modem, flash memory card to a teapot warmer. Just about the only kinds of devices that it doesn't handle well are ones that require a very large bandwidth, like a video adapter.

The USB specification has a very elegant protocol specification that describes how devices can share the bus and how they can exchange data. That protocol spec however does not describe the format of the data at all, it merely defines the notion of being able to deliver chunks of bytes. It is up to the device itself to give a meaning to those bytes.

On the machine end, you need software to interpret those bytes and make the machine do something interesting with them. That requires a device driver. Just like your video card and your network interface card require a device driver. Obviously a video driver is very different from a NIC driver. The same is true for USB drivers, there is little commonality.

If you want to write software that treats USB devices similar then you need to write that at the level where they still have something in common. That's at the USB controller level, you could write a filter driver that injects itself in the USB driver stack and peeks at the I/O request packets between the controller and the device driver. Similar to, say, the winpcap filter driver that spies on TCP/IP traffic. There isn't much of anything interesting to see though, you'd be staring at the blobs of bytes that pass back and forth. It is a much bigger problem than winpcap, at least it sees bytes fly by whose meaning is documented somewhere in an RFC. That's not the case for USB, the company that makes the USB device is also usually the device driver supplier. They keep the internal format undocumented.

Writing filter drivers requires pretty advanced skills, there are lots of pain points. Like crashing the operating system when you make a simple mistake. There has also been considerable flux in the Windows Driver Model lately, USB drivers have been getting moved into ring 3 (user mode) to keep the operating system stable.

To get started, download the Windows WDK (aka "DDK") and read Walter Oney's books. Preferably all of them.