<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Charles Lepple wrote:
<blockquote cite="mid:04037C45-D2C1-40E7-B513-C66FF897A753@ghz.cc"
type="cite">
<div>
<div>On Jan 8, 2010, at 8:55 AM, Tim Nicholson wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">The Microchip URL where the
download can be found is <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2651&param=en534494">http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2651&param=en534494</a>.
(The framework comes in the form of a zip file which, unfortunately, is
pretty large even by modern standards).<br>
</div>
</blockquote>
<div><br>
</div>
<div>Is this the .zip file with a .exe in it? Or the legacy
"LPCUSBDK_Labs_V3.zip" file?</div>
<br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">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.</div>
</blockquote>
<div><br>
</div>
<div>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.)</div>
<br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> 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.</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>You might want to compare the libhid source code and API
documentation to that of libusb:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://libhid.alioth.debian.org/doc/hid__opening_8c.html">libhid:
hid_opening.c File Reference</a></div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://libusb.sourceforge.net/doc/">http://libusb.sourceforge.net/doc/</a></div>
<div><br>
</div>
<div>In the case of finding and opening a USB device, libhid is not
doing much besides wrapping the libusb calls.</div>
<br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> 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!<br>
<br>
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.<br>
</div>
</blockquote>
</div>
<br>
<div>That's the thing - the answer to that question depends heavily
on the firmware on the device.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Again, since your report descriptor only has one report in each
direction, and no Report ID fields, this simplifies things somewhat.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>[*] Directions are all relative to the host computer: PIC-to-PC
is input, and PC-to-PIC is output.</div>
<div><br>
</div>
<div>Also, you might search here to see if there is already some
example code that could talk to the default firmware:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://mcuee.blogspot.com/search/label/USB">http://mcuee.blogspot.com/search/label/USB</a></div>
</blockquote>
<br>
<br>
Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Tim<br>
<br>
</body>
</html>