Nugget: 1 of n : GEtting started with USB communication via VISA

[Daklu]

Great topic Shane!

For five years I worked as a test engineer developing computer mice and have to agree that the USB spec as a whole is difficult to understand.  I never did feel like I knew enough to confidently talk about it.  Unless I worked with it on a daily basis (which I rarely did) I tended to forget what I had learned and frequently had to refer to the spec.  That being said, there is one thing in particular you can do to increase your chances of success with USB.

Focus only on what you need to know.

Don't try to understand the entire spec.  The USB spec covers everything -- mechanical & physical elements, low-level electrical requirements, firmware requirements, etc -- for every type of device that can be connected via USB.  Trying to absorb all of it right off the bat is asking for trouble.  Assuming most people here are focused on software interfacing with the device, here are a few sections of the spec to focus on:

• Chapter 4.4 - 4.10 (6 pages) Architectural Overview
• Chapter 9 (35 pages) USB Device Framework.  This describes the messages that pass between the USB host and device.

These two chapters will help you understand what you are seeing on your USB sniffer.  Depending on your specific application, you may decide to dive into chapter 5 - USB Data Flow Model, chapter 8 - Protocol Layer, or chapter 10 - USB Host: Hardware and Software.

Figure out what class your device is and ignore the rest.  Mice, for example, are part of the HID class.  Since they are simple devices there is a lot of the spec that simply does not apply to them.  Generally mice don't do isochronous or bulk data transfers instead limiting themselves to control and interrupt transfers.  They use a limited number of device requests and many listed in chapter 9 won't be applicable.  Oh, and be sure to get the device class definition for your device class.  The one for HID devices is here.  There are other documents that may be useful here.

Here's a vi I put together to read USB descriptors.  I used this for a specific problem concerning USB-8451s to get the Vendor ID and Product ID.  You may be able to adapt it to suit your needs.  You should be able to read the device descriptor of any USB RAW device as is.  Refer to USB Spec chapters 9.4, 9.5, and 9.6 if you start poking around in it.  Specifically, you may need to change the request type and descriptor index if you try other bRequests or Descriptor Types.

[Intaris]

Well, getting a keypad to NOT show up as a system input device is simple.  You install it using a VISA RAW driver via the VISA driver wizard (details HERE).  It WILL show up in device manager, it just won't be linked to the standard inputs as a keyboard or mouse would normally be.

Once the non-standard driver is loaded, the OS will not see it as a HID input device, as VISA will have custody.  Unfortunately, it's a one-or-the-other thing at the moment.  I'm sure it's possible to feed the input back into the system if required, but that's a whole different kettle of fish.

The tinmeout in the code can be used to allow the the spawned process to periodically check for a termination condition.  I had originally put some "See if the parent is still running" code in there.  I don't have the code in front of me (I'm just popping off to bed) so I don't recall if this is still the case or not.  Otherwise, since the spawned process quits when the VISA port is closed, it's not actually necessary (closing the Port will create a VISA error).

It's really only a starting point (this nugget).  There's so much more to the topic of USB, I'll have to cover control transfers later before anyone will be able to get much mileage out of the information beyone mice or keyboards.  Bulk is kinf of important too, depending on the device being used.  I'm currently unawre as to whether VISA can do Isochronous transfers.....

The nugget was originally more than double this length until a clever teddy bear suggested it might be a bit long.  Which it was indeed.

Shane.

PS Re. LVOOP code.  I have my own ideas at the moment, but it has more to do with automatic parsing of Reports than anything else.  That's a complicated topic in itself (maybe a different nugget on the topic in the future).  In this way, a universal HID driver should be realisable.

[Daklu]

PS: A generic mouse driver would be possible using LVOOP, allowing for the support of multiple models. How would go about this? What would the base-class look like? How would you interface to the host program? How would you handle other HID classes (Joysticks, touchscreen panels and so on)?

If you are asking about supporting multiple mouse models, I think it would be fairly straightforward.  Mice have to conform to the requirements set out in the HID Class Definition which defines the position reporting packet.  It covers 3 mouse buttons and x-y position.  If you need to implement additional buttons or a scroll wheel you'd probably want to have a child class inherit from it.

If you're asking about creating a class hierarchy that can support all USB devices, that's something else entirely.  For instance, in your first post you listed all the different device classes.  At first glance you would have a generic USB Device class as the base class with each 'USB Device Class' (as defined in the USB spec) inherit from it.  However, as I understand it the device classes are more like interfaces than hardware-based divisions.  A force-feedback joystick fits in both the HID device class and the physical device class, and as such implements features of both of them.  It certainly would be an ambitious project.

Message Edited by Daklu on 07-14-2008 03:55 PM

[TCPlomp]

---

@Intaris wrote:

PPS: The code shown here may be useful as an introduction to USB, but can anyone think of any actual application which can benefit from a non-system pointing device or keyboard?

Message Edited by Intaris on 07-14-2008 11:34 AM

---

LabVIEW realtime?
See here:

---

The reason I wrote these VIs is because I wanted some user input to a program running on a PXI system running LabVIEW Real-Time. Since there is neither mouse or USB support, this was the best solution I could come up with. There, of course, leaving the mouse/trackball attached to the COM port all the time is just fine.

---

Ton

[Intaris]

Daklu,

Thanks for the clarifications regarding the chapters of the USB spec.  True, chapter 9 is by far the most interesting for the communication via software.

Regarding the LVOOP approach I was thinking more of a generic HID driver.  Most other classes have prohibitive entry barriers (ulaw Audio codecs and so on) to be able to use them with a "universal" driver.  For anything other than HID (Or perhaps Mass storage) it's not really feasible.

The problem with just implementing a child class for a mouse with wheel is that there are many different HID devices out there which may also have a wheel but aren't mice.  How to handle these?  I have already started parsing the HID reports, but this is something which is relatively compilicated.

Shane.

[Intaris]

TonP,

I was unaware that LVRT didn't have standard mouse input possibilities......

Does LVRT have £USB-support in VISA?

Shane.

[Britoa]

 A lot of information here, wow.  One book that I think goes over the USB spec pretty well is <a href="http://www.lvr.com/usbc.htm">USB Complete</a> by Jan Axelson.

It goes over everything I needed to know to make my own USB device in assembly (PIC microprocessor, USBTMC device, com through VISA, processor speed wasn't worth doing it)

[rpr]

Wow Wow intaris what a great effort. When i can understand it u can be rest assured that anyone can. Seriuosly thanx for sharing the info

[Ben]

Daklu posted

"Here's a vi I put together to read USB descriptors.  I used this for a specific problem concerning USB-8451s to get the Vendor ID and Product ID.  "

I have to acknowledge that is much better than some of the approaches I have used to handle the issue of NI USB DAQ devices chaning their address. My solutions were "Try to do an I/O and see if it works" or "Read the device serail number". Both of these were very crude or too tightly coupled to the hardware.

Nice Daklu!

Ben

[Intaris]

I bought "USB Complete" also but was a bit disappointed that it was very windows-oriented.

Re: Descriptors.  This is basically a part of the "Control" transfers which I'll be highlighting later.  I haven't been able to look at Daklu's code yet (8.2.1 here) bit will do soon.  I imagine it's similar to what I've been doing also.  On top of the device descriptor, there are also configuration descriptors, interface descriptors, endpoint descriptors and HID descriptors.......  It starts getting a bit involved once you get going.

It's aqlso possible to do a static (usb-IF has a text file with all vendor IDs and names) or dynamic (strings stored on the device) evaluation of the name of the manufacturer also.

All the stuff of nuggets yet to come.....

Shane.