On Jan 8, 2010, at 8:55 AM, Tim Nicholson wrote:
The Microchip URL where the download can be found is http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2651¶m=en534494
. (The framework comes in the form of a zip file which,
unfortunately, is pretty large even by modern standards).
Is this the .zip file with a .exe in it? Or the legacy
"LPCUSBDK_Labs_V3.zip" file?
I have not made any changes to the demo source code as yet, as I was
just trying to interface with the standard demo software as a first
step.
If it's files from the .exe, and the source code license isn't too
restrictive, can you post just the key files somewhere? (I don't have
any Windows machines running here.)
My final application will not be much more complex as all I need
to do is detect some key presses and read the ADC on the PIC. The
ability to read and write single 64-byte buffers is all I am looking
for. I will have a look at libusb, to see if I can make any sense
of that.
By the way, when I mention "libusb", I am referring to the legacy
version, libusb-0.1.12. There is a new version out (1.0), but your
embedded Linux host might not have packages for it.
You might want to compare the libhid source code and API documentation
to that of libusb:
libhid: hid_opening.c File Reference
http://libusb.sourceforge.net/doc/
In the case of finding and opening a USB device, libhid is not doing
much besides wrapping the libusb calls.
My biggest problem is I am very new to USB and I am finding all the
terminology difficult to get my head around. All of the Microchip
texts and examples are designed for Windows developers which is fine
except my final application will be running on embedded Linux and I
have not really had anything to do with Windows software development
since the mid 90's. I have tried looking at the USB specifications
but trying to tie it altogether is not proving very easy - I am
suffering from information overload!
Any pointers would be much appreciated. I just need to understand
what functions I need to call to establish a connection and transfer
data to and fro.
That's the thing - the answer to that question depends heavily on the
firmware on the device.
For HID-class devices, there are two main paths: control transfers,
which allow you to pick which report you want (moot in your case,
since you only want either the input report or the output report, and
the direction of transfer is encoded into the request), and interrupt
transfers, which simply get the next available input* report from the
device, or send a an output report to the device.
Again, since your report descriptor only has one report in each
direction, and no Report ID fields, this simplifies things somewhat.
In an ideal world, the firmware would treat the control transfers and
input transfers similarly, reading and writing the same buffers. When
I was working with the PIC16C765, I don't think that was the case.
[*] Directions are all relative to the host computer: PIC-to-PC is
input, and PC-to-PIC is output.
Also, you might search here to see if there is already some example
code that could talk to the default firmware:
http://mcuee.blogspot.com/search/label/USB
_______________________________________________
libhid-discuss mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/
