discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard


From: Thomas Tsou
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
Date: Mon, 28 Feb 2011 01:14:23 -0500

On Sun, Feb 27, 2011 at 11:39 PM, Almohanad Fayez <address@hidden> wrote:
> I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.
> I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation
> fails because of the libusb-0.1.12 link, more specifically the
> "libusb-gnur.a" library.  For some reason GCC is expecting the library to
> have the "-fPIC" flag passed when building the library which doesn't make
> sense since it's trying to link against a static library and not a shared
> librar ... it was complaining about an ARM_MOV or something like that
> assembly command.  To my understanding the libtool included in the libusb
> should make sure that such confusion doesn't happen which in using GCC 4.3
> was not an issue but with the GCC 4.5 included in the new tree is an issue.

UHD uses libusb-1.0 and does not support libusb-0.1. Despite some
similarities in the API, version 1.0 is a complete rewrite there is no
compatibility or relation between versions. In that sense, the
gnuradio 3.2 recipe is completely unrelated to UHD.

> I also tried incorporating the libusb fix against the GNU Radio GIT recipe
> but the configure stage fails because gnuradio can't find the
> "USB_BULK_WRITE" function in the libusb library from libusb-0.1.12 which
> when I looked is actually there.  When I bypass the configure check for
> USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio
> 3.2.1.  I feel like the libusb-0.1.12 static library is corrupt for some
> reason more specifically I think libtool might be the culprit.

If you are using libusb-0.1 and the gnuradio driver, you generally
_don't_ want to be using the mentioned libusb calls, which are
synchronous (slow). Normally, with libusb-0.1, the control and setup
functions go through libusb, while data flows through a separate OS
specific implementation - usbdevfs in the case of Linux. The only time
you should be seeing usb_bulk_write is when configure falls back to
the synchronous calls in the absence of any "fast" version. Now the
Linux implementation does have some evil bits, so perhaps this isn't
surprising.

> I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might
> explain why I can receive but I can't write using the UHD driver.  The
> libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use
> libusb-0.1.12? an older or newer version maybe?  did it use a different
> libtool?

Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD.

> I need to find a way to pass the -fPIC flag to the configure stage of
> libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and
> I'm about to head out of town for a few days.  Other than that doese anyone
> have any suggestion?

In UHD with libusb-1.0, sends and receives are treated similarly (USB
is host driven) where pre-allocated buffers are submitted and
retrieved from the device. The difference is mainly in flags and
endpoint settings; the problem, IMO, is unlikely to be build related.
Of course, that doesn't provide any insight into why this is only
coming up on the Beagle.

I'd like to recreate this issue on my newly setup E100, but, at the
moment, I'm not seeing any USB devices, and I think I just bricked my
FPGA. So I need to get a little bit more settled until I can try out
additional things. Perhaps later this week...

  Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]