10-21-2008 05:38 PM
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,
10-21-2008 05:45 PM - edited 10-21-2008 05:45 PM
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)
10-21-2008 06:02 PM
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)...?!
10-21-2008 06:04 PM
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.
10-21-2008 06:13 PM
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"?
10-22-2008 06:41 AM
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.
10-22-2008 06:51 AM
09-02-2009 11:51 AM
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.
09-02-2009 02:20 PM
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.
11-06-2009 01:02 AM