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

[golubovski]

Intarias,

I opened a thread recently wth the followoing post and was adviced to look at this educational thread of yours. I would appreciate if you could help me get going - how to treat my PIC device (class ???), how to register it and how to access it:

_____

I wasn't sure which board is the correct address for my post. I have a custom (home) made PIC based piece of hardware doing DAQ that needs to be contrled via USB. I have no experience with programming USB at all so I don't know where to begin learining from. I guess the first step is to identify the particular USB port, than to open session, write/read byte streams and close it - but don't know how to do this in LabVIEW.

I have search the Developer Zone but the articles I found are advanced for me and I cannot follow. Can somebody  help me with this? The PIC will do DAQ constantly and time-stamp it. My LV app needs to read from it a string of sampled values per channels. Upon certain circumstances I need to send to the PIC cmd for him to do DIO action via relays. So there is no formal serial protocol implemented, and unlike the COMs I don't know how to identify the USB part the PIC is connected to.

_____

Thanks in advance, 

[Intaris]

What type of device are you trying to interface with?  Is it a member of the "Test&Measurement" device class?

Do you have a protocol description? Are you working under Windows?

Shane (a.k.a. Intaris)

Message Edited by Intaris on 10-21-2008 05:45 PM

[golubovski]

Shane,

Thank you for the prompt response!

It is a custom build PIC-based PCB for time-stamped DAQ of 20x AI, 1x AO and 3x DO (relays). The PIC is from Microchip, I'm not sure which one. The protocol will be defined according to my wish. I plan to send cmd (a byte) to trigger a response consisted of all values sampled - so I will poll it. The string will end marked with a certain byte(s).

OS is Windows. I am completely dummy regarding the class issue.

I gues I have to identify it to become visible for the system (like COM2, etc.) - I don't know how to ID the USB ports (hubs)...?!

What next...?

[Intaris]

You need to try to install a VISA driver as pointed out to you in the other post you made.  It's also detailed in this thread.

Do you have any details on the communication details of the PIC you're using (Bulk, Interrupt, Control transfers)?  If not, you'll be hard done to have something up and running in a short time.

Shane.

[golubovski]

I'll have the PCB this weekend and will try to setup a driver. Concerning the transfer type (bulk, interrupt, control) - does it depend on me? I obviously just need to send cmd to poll the PIC and occasionally to send cmds to make him switch ON/OFF the relays. So its not an "interrupt" transfer I guess. What is the difference between "bulk" and "control"?

[Intaris]

I don't see how you're going to get communication up and running from scratch without SOME documentation on the USB driver chip you're using.

Control transfers MUST be supported, as these are used for device enumeration.  If you have the choice and want to keep things simple, stick with control transfers.

If you want the device to send a message back when something is done (indeterminate amount of time) this would use interrupts.

There's no need to consider bulk unless you need fast transfers.

Have you read my thread on the subject?  Try downloading the USB spec and having a read of chapter 9.  It's a lot and much of it you won't need to understand but it gives an insight into how USB works and what the different transfer modes are.

Shane.

[Britoa]

The PIC processors that do USB can do any transfer type, but you do have to set it up yourself entirely.  If you haven't done anything with the PIC and USB, I would suggest checking out the Microchip forums (forums.microchip.com if I recall) and look for posts by bminch (I think, if I'm wrong, let me know, and I will find the right post after work).  He teaches courses using the PIC and USB, and has some sample code, well documented, in both C and assembly posted. 

[EML]

Thanks Intaris!

I used this tutorial to interface to a USB keyboard.  I was suprised to find that USB keyboards do not use traditional scan codes, at least not my Dell Keyboard.  I have attached a pdf of the USB keyboard codes for others to use.  Opt commands like Alt, Shift, and Crtl are returned in the first byte. The rest of the key's values are returned in the third byte and simultaneous key presses in the subsequent byte fields. The allowable number of simultaneously pressed keys varies by location on the keyboard and relative position of keys (horizontal vs. vertical)  This is probably due to the scan matrix in the keyboard.  

Enjoy,

-Eric

[Intaris]

That's the standard "boot protocol" implementation of the Keyboard data.  It's required so that a BIOS knows what to do with the data before the OS has loaded.

All of the data is available in the HID specification found HERE.  Heading 8.3 is what you're looking for.

Shane.

[nunk]

Hi Itaris,

Thank you for sharing this Nugget,it helps me a lot.
however I got a problem as you had metioned before.
"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."

Do you have any further study in this case? or any advice? i want to feed the input back into the system in my mice test project.