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

[Daklu]

---

Intaris wrote:
Regarding the LVOOP approach I was thinking more of a generic HID driver. 

---

I suppose you could implement the HID Device Class spec as a base class that would give you basic mouse and keyboard functionality.  The problem is the spec needs to account for all sorts of corner cases that most users will never encounter, which of course adds to the complexity.  (I have yet to run across a device that uses my cheek or little toe to activate it.  HID Device Class spec p 46.)  If you want a truly generic driver you'd need to implement all that 'extra' stuff.  It would be interesting as an academic exercise, but I think it would have limited real-world value.  (Don't let my opinion stop you from doing it though.)

---

Intaris wrote:
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'm really rummaging through the depths of my memory for this, so I may be wrong...

Since the wheel is not a standard field in the HID Device Class spec, any wheel implemented will report its data via device-specific fields.  (See appendix B.2 in the HID Device Class spec.)  You have no way of knowing beforehand where a device will put that data or what the data will look like.  Some will tack it on the end of byte 0, others will use byte 3 or above.  Some wheels are implemented with up as positive, others are implemented with down as positive.  In short, you can't create a generic solution for the wheel.  A device with a wheel would need to inherit from the base class and implement custom code to find and interpret the data.

BTW, have you ever bought a fancy new mouse and plugged it in before installing the drivers?  Did you notice how much functionality you had?  Position and three buttons... which coincidentally happens to be those fields defined by the HID Device Class spec.  You need to install the drivers to get all the additional functions.

-------

Attached my code for LV 8.2

Message Edited by Daklu on 07-15-2008 12:01 PM

[Intaris]

Daklu,

Yeah, I've noticed the three buttons and position thing many times, I referred to it in the nugget also.  It's the reason why button 4 and 5 on my Logitech MX518 don't work with the standard Linux driver.

As you say, the HID report contains all you need to know about the data being sent.  The physical descriptor thing (toe, cheek, eyebrow, index finger) is relatively simply as it's just a data field.  It doesn't modify the values in any way.

As to a HID class, I was thinking more along the lies of a SINGLE HID class with each element of the report being a class.  In this way we'd have a LVOOP approach to the report instead of the device which is kind of closer to the real challenge of the exercise.  Sure it's not guaranteed to be a big hit on the "free market" but it could be made into a nice community project.  Maybe NI will like it and I'll get a LV for Linux and LV for Mac license to test the multi-platform nature of the code......

As mentioned, the challnege with the HID class isn't the device, that's relatively simple (Standard control commands plus interrupt data transmission).  It's trying to work out what the data is which is the real challenge.  The other method is a device-for-device case which is easy (well, easier), but kind of inflexible.

But we're getting ahead of ourselves.  Would it be OK if I send you a draft of the next nugget before posting since you seem to have some experience in the area?

Shane.

[Intaris]

I've just had a look at your code.

Not bad, but there's a lot of Info in the descriptor you're not interpreting (at least in the posted version of the code).

Looks like I'll have to shift my date for the next nugget forward a bit.  We're already getting into some of the heavier stuff of at least two other nuggets (Control transfers and HID reports).  Two things I've learned a lot about in the last time.

I have a simple parser for the entire device, configuration, interface and endpoint descriptor which displays all data associated with the descriptors.  I have a HID descriptor parser too, but that's WAY more complicated.....  So in a way, I already have quite a lot done.  Best way to learn USB in my mind.

I hope the upcoming USB 3.0 doesn't mess with my newfound knowledge too much.....

Shane.

PS, the "Cast" to USB raw in your code in interesting.... Is this a way we can get around having to install an extra driver to get VISA communicating with the device (under windows)?  Can we get a handle to the system mouse this way?


Message Edited by Intaris on 07-15-2008 03:11 PM

Message Edited by Intaris on 07-15-2008 03:11 PM

[Daklu]

"Would it be OK if I send you a draft of the next nugget before posting since you seem to have some experience in the area?"

"Some" is the operative word here.    You certainly can send it to me if you want but I think you've done a fine job with your nuggets so far.  (I hope my posts haven't come across as critical of your nuggets.  That's not my intent at all.)

"As to a HID class, I was thinking more along the lies of a SINGLE HID class with each element of the report being a class."

I'm not sure I understand yet.  Can you explain what you mean by "each element of the report?"  Is the single HID class essentially a container for all the element classes?

"...there's a lot of Info in the descriptor you're not interpreting."

Yep, I was only interested in getting the Mfg ID and Product ID, so that's all I parsed.  (I was having trouble with the 8451 dropping off-line so this is how I checked to see if it was responding.)  The other stuff is in there only because I was poking around while relearning (again) what was going on.

"the "Cast" to USB raw in your code in interesting.... Is this a way we can get around having to install an extra driver to get VISA communicating with the device (under windows)?  Can we get a handle to the system mouse this way?"

Contrary to the way it appears on the block diagram, the 8451 isn't VISA compatible.  I had to cast it to a RAW device so I could use the VISA USB vis.

No, I don't think you can get a VISA handle to a system mouse since the system mouse isn't an instrument.  In fact, I don't think VISA supports most (any?) of the USB Device Classes, meaning you'd have to configure all your HID devices as USB Raw and lose your system-level functionality.

"I hope the upcoming USB 3.0 doesn't mess with my newfound knowledge too much..... "

Much like USB 2.0 is backwards compatible with 1.0, 3.0 will likely be compatible with with 2.0.  What you know won't change, there will just be more to learn. 

[Intaris]

Daklu,

your "some" experience with my "some" experience adds up to more than I have.  Sometimes a second pair of eyes helps in spotting glaring mistakes.  I'm still new to USB, so I give all this USB information with a healthy and sometimes large pinch of salt (and should be taken as such).

Regarding a HID class, I was thinking of a single "device" class since all HID can be interfaced int he same way basically.  Once the report is received, it's the parsing of the report and the creation of the appropriate events (or messages) which distinguished the different devices from each other.  The report is made up of a number of different elements, each of which has its own "mechanical action" so to speak.  This, plus the fact that there are a pre-set number of HID events to be raised makes it seem like an array of objects for interpreting the report (bit for bit) would make sense where each object knows when to raise an event and when not, whether the data sent is boolean (button) or scalar (mouse poisition) and so on.  So the HID device would be a single class containing an array of sub-objects (not children) for helping interpret the report(s).

So the short answer to " Is the single HID class essentially a container for all the element classes?" would be Yes.

Shane.

[Ben]

Daklu and Shane,

You two are doing a great job of working through the forest of USB spec to show a path that we will bea able to follow.

Q:

RE: class structure, Would a parent class for all  USB devices all adaptation of mouse implementation to other classes of devices?

Thank you both very much!

Ben

[Intaris]

Ben,

No, the "Hid" class would be valid only for HID devices, so not for anything beyond  mouse, keyboard, VR-glove, steering wheels and so on.

The reason is that the class needs o be tailored to the "type" of device.  HID is only one type, which defines a common framework (Interrupt data reports, meaning of the data in reports and so on).  None of this applies to devices of other classes.

One thing common to all USB devices are the control commands, which I'll try to cover (sooner rather than later) in the next nugget on the subject.  They would form the "base class" for all USB devices, from which HID would be a child.

Shane.

[Daklu]

"Sometimes a second pair of eyes helps in spotting glaring mistakes."

Sure thing.  I'll be happy to run it through my spell-checker.    You can send it to me at v-davsny@BigSoftwareCompanyInRedmondThatEverybodyHates.com

"So the HID device would be a single class containing an array of sub-objects (not children) for helping interpret the report(s)."

I'm no class designer so I'm sure I'm missing something here.  Why would you use classes and objects within the generic HID class?  It seems like it's adding an unnecessary layer of complexity.  Is there an inheritance structure within the generic HID class?

I *think* I understand your intent a little bit better.  Tell me if this is correct... The generic HID class will parse and report all the standard data in the USB transaction, such as mouse position and keyboard buttons.  Non-standard data, such as a scroll wheel, will be reported in a generic format.  For example, it could be a cluster with a string and integer where the string contains the string descriptor of the data and the integer contains the value.  For non-standard data, the calling vi will be responsible for knowing what string descriptors to look for and how to interpret the data.  Am I close?

BTW Shane, I went back and read the beginning of the thread.  Somehow I missed all of part 4, except for the questions at the end.  In the future I'll try to remember to actually read a thread before responding to it.  (No promises though.)

"You two are doing a great job of working through the forest of USB spec to show a path that we will bea able to follow."

"Forest" is an apt description.  But it's not a nice old growth forest with towering redwoods... it's a tropical forest with tangly bushes, poisonous creatures, and unexpected rivers all preventing you from making progress.  Occasionally you stumble upon some ruins and say, "Aha!  This is what I'm looking for!"  Nevertheless, I'm glad you're finding value in the discussion.  FWIW, although I have to relearn everything whenever I get into USB again, every time I understand it a little bit better.  Two steps forward, 1.9 steps back.

"Would a parent class for all  USB devices all adaptation of mouse implementation to other classes of devices?"

I'm glad Shane responded to this.  I can't even get my brain to parse the question into something meaningful. 

Message Edited by Daklu on 07-16-2008 08:33 AM

[Intaris]

"Would a parent class for all  USB devices all adaptation of mouse implementation to other classes of devices?"

At first I thought this sentence didn't make sense, but then I thought that the letters "ow" were missing, which happens to be how my brain feels when I'm reading the USB spec.

so.... "Would a parent class for all  USB devices allow adaptation of mouse implementation to other classes of devices?"
I don't know if this is what Ben meant, but it's the question I was trying to answer at least....

The advantage of having objects contained within the class allows different types of reports (value, boolean, different latch types, different Events to fire) to be stored in an array.  This allows each TYPE of report data to have its own code, but still allowing a simple array containing all the elements of the report.  Simple.  Parsing the report is then done with a simple for-loop and the report object array.....

Shane.

[Daklu]

"...but then I thought that the letters "ow" were missing, which happens to be how my brain feels when I'm reading the USB spec."

ROFL!