[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Unable to find USRP
From: |
Berndt Josef Wulf |
Subject: |
Re: [Discuss-gnuradio] Unable to find USRP |
Date: |
Mon, 16 May 2005 04:12:01 +0930 |
User-agent: |
KMail/1.7.2 |
On Sunday 15 May 2005 11:28, Eric Blossom wrote:
> On Sun, May 15, 2005 at 10:13:03AM +0930, Berndt Josef Wulf wrote:
> > > This is similar to the problem I had with the audio device that doesn't
> > > permit it to be opened by two or more processes, see the lines
> > > containing EBUSY. I will try to figure out which part of
> > > benchmark_usb.py doesn't close the ugen device.
> >
> > The problem is that benchmark_usb.py opens usrp.sink() and usrp.source(),
> > both which use the open() calls to access the device. On *BSD this is not
> > possible and is exactly the some problem as seen with the audio.sink()
> > and audio.source() function that I hacked around.
> >
> > A possible generic solution to this is to acquire the filedescriptor for
> > the device which is then used by the subsequent calls. e.g.:
> >
> > usrp_dev = usrp.open() <- instantiate device
> > sink = usrp.sink(usrp_dev, ....) <- open source
> > source = usrp.source(usrp_dev, .....) <- open sink
> >
> > similar for other sink/source devices that are used with GnuRadio.
> >
> > Else, *BSD will not be able to run scripts that use sink and source of
> > the same device simultaneously..
> >
> > cheerio Berndt
>
> My humble suggestion is that somebody fix the NetBSD libusb
> implementation, or if that isn't possible, then fix the usb ugen
> device driver. If what you describe is true, it's totally asinine
> that different processes can't open different end points of a given
> USB device. What purpose does such a limitation serve? Instead of
> trying to work around broken code, fix the broken code.
>
> We do expect to be able to open end point 0, the designated usb
> control endpoint, by more than one processes. It's how we configure
> the USRP. The Rx code is smart enough to only mess with Rx related
> settings, and likewise for the Tx code.
>
> If the ugen driver has code that forces exclusivity, it ought to be
> simple enough to remove it (at least on end point 0). Search for
> EBUSY in the driver source. It's probably in the first 10 lines of
> the open routine.
>
> Eric
Thanks for your help. On inspection of the ugen device driver I can confirm
that it implements exclusive access to the control endpoint. After modifying
the driver to allow multiple access to the control endpoint benchmarks_usb.py
works fine.
I'm not familiar with the USB specifications, but from what you're saying did
I understand you correctly that multiple access to USB Control Endpoints is
permissible, but access to other endpoints are exclusive to one process? If
so, we just found a bug in the kernel.
In any case, I'm happy to report that, using a modified kernel, the benchmark
utility is working now.
cheerio Berndt
--
Every man who says frankly and fully what he thinks is doing a public service.
[Leslie Stephen]
- Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails), (continued)
- Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails), Berndt Josef Wulf, 2005/05/02
- [Discuss-gnuradio] Unable to find USRP, Berndt Josef Wulf, 2005/05/13
- Re: [Discuss-gnuradio] Unable to find USRP, Eric Blossom, 2005/05/13
- Re: [Discuss-gnuradio] Unable to find USRP, Berndt Josef Wulf, 2005/05/13
- Re: [Discuss-gnuradio] Unable to find USRP, Eric Blossom, 2005/05/13
- Re: [Discuss-gnuradio] Unable to find USRP, Berndt Josef Wulf, 2005/05/14
- Re: [Discuss-gnuradio] Unable to find USRP, Eric Blossom, 2005/05/14
- Re: [Discuss-gnuradio] Unable to find USRP, Berndt Josef Wulf, 2005/05/14
- Re: [Discuss-gnuradio] Unable to find USRP, Berndt Josef Wulf, 2005/05/14
- Re: [Discuss-gnuradio] Unable to find USRP, Eric Blossom, 2005/05/14
- Re: [Discuss-gnuradio] Unable to find USRP,
Berndt Josef Wulf <=
- Re: [Discuss-gnuradio] Unable to find USRP, Eric Blossom, 2005/05/15
Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails), n4hy, 2005/05/02
Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails), Eric Blossom, 2005/05/02
Alternate list archive locations (was:Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails)), Lamar Owen, 2005/05/02