Charles Lepple wrote:
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&param=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:



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:



Hi,

I have managed to get it all working now using libusb 1.0. The documentation for that API is extremely good and everything was up and running in just a few hours. For some reason I had assumed that libusb was a much lower level library that it actually is. That is the problem with going into things blind and trying to piece it all together from fragments of information gleamed from various forum posts. It is now clear that the libhid route was completely overkill for what I wanted to do.

Unfortunately, I do have the luxury of a package manager! Absolutely, everything is built from scratch on the embedded platform - To be honest, that is really the only way to do it with embedded linux otherwise you just endup with a dinosaur and might have well have used Windows CE! Building Linux systems is my area of expertise and I have been doing it for years so I don't foresee many problems in that area. What I like about libusb 1.0 is that it handles asynchronous transfers whereas 0.1.x only handles synchronous transfers. I also like to use the latest stable versions whenever possible because they tend to work better with the newer tool-chains.

Thanks for all your help, I am pretty much there now and I am beginning to understand how USB hangs together much better. It always amazes me how something that seems so complicated can become so much easier with just a pointer in the right direction - Thanks.

Tim

_______________________________________________
libhid-discuss mailing list
libhid-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

Reply via email to