Re: OMAP3 (was Re: [Discuss-gnuradio] Discuss)

[Eric Blossom]

On Thu, Mar 19, 2009 at 06:18:53PM -0400, Philip Balister wrote:
> Eric Blossom wrote:
>>>
>>> Philip mentioned in a previous post that Angstrom can be built with
>>> libusb-1.12 as a workaround so we can look into some sort of kernel hacking
>>> as well.  But if there were a better approach than this it would be useful.
>>
>> No kernel hacking is required.  libusb-* is a user space library.
>
> There are some tricky dependencies in the OE build system that make  
> mixing libusb-0.12 and libusb-compat tricky. Making the switch is a  
> little easier todo now OE uses git.
>
> My desk is a disaster at the moment. I need to fabricate a small board  
> organizer so I can get some work done.
>
> Dan, can you build the latest from OE? I switched gnuradio recipe so it  
> builds from svn, with the fff fir filter converted to NEON (so it runs  
> faster). When you update OE, the packages directory is now called  
> recipes, so you will need to change BBFILES and BBPATH vars. I'll see if  
> I can supply a patch to OE meta-data that uses libusb-0.12 again.
>
> Longer term, I am hopeful I can work out how to find the required bits  
> from libusb-compat and eventually hope that the improvements in libusb1  
> resolve the performance issues.
>
> Philip

One approach is to write a new fusb_* variant (fusb_libusb1?) that
uses the 1.0 API directly.  We could select the appropriate variant at
configure time based on the version of the libusb library we find.

Of course, if the new libusb-1.0 API can't sustain transmitting and
receiving at 32MB/s, then we'll need to try something else.

Any volunteers out there who'd like to take a look at this?

Besides fusb_linux.{h,cc}, you'll probably want to look at
the much simpler fusb_generic.{h,cc} for ideas.

Eric