On Sun, May 01, 2005 at 08:27:34PM +0200, Harald Welte wrote: > Hi! > > AFAICT, at the moment there is no way to use a single USRP from multiple > application programs at the same time. This is quite unfortunate, since > you might want to run a transmit and a receive program that are totally > independent (or even two tx and two rx programs).
> While browsing through the usrp fx2 firmware and the low-level host-side > code, I learned that there are three seperate usb interfaces which one > endpoint each. What was the idea of splitting control/in/out to > seperate interfaces? The Tx and Rx sides are completely independent and we often run different apps for Tx and Rx simultaneously. The Tx and Rx paths have different USB endpoints for their streaming data. This is what allows different apps/processes to open them. They share a common control endpoint (EP0), but that can be opened by more than one processes since only usb command packets are used. > Wouldn't it be nice to actually provide multiple interfaces that each > correspond to a certain amount of USRP hardware? This way each > interface can be claimed by a seperate program. Yes. However, the FX2 is limited in the number of endpoints that it supports. See page 15 of the CY7C68013 datasheet. Right now we are running with endpoints 2 and 6 "quad buffered", 4 512 byte buffers each. One is used for Tx data, the other for Rx data. It would be possible with a bit of hacking to run endpoints 2, 4, 6 and 8 "double buffered", 2 512 byte buffers each. That would give us 4 bulk endpoints to work with (and would also lower the worst case latency). > Seperating it into four interfaces (2rx, 2tx) might be complicated, > since there certainly are shared data structures and functional blocks. Mostly the complication comes in the FPGA. As implemented, all 4 DACs and their signal processing code are in one clock domain and run their signal processing paths in parallel. This is where the constraint on using the same interpolation factor comes from. The situation is the same on the Rx path and leads to them requiring the same decimation factor. > Providing two interfaces (one for each AD9862) should be easier, > since full control over a singe AD9862 would be in one program. Not the issue. We already split control over the Tx and Rx parts of a given AD9862 across processes. > I haven't yet looked at the FPGA verilog, but maybe you can give me some > comments on whether you think > > 1) this is a good idea (and was planned but never implemented) > 2) there are any serious known issues (which?) > > If it looks feasible, I would probably be looking into that issue. May be feasible, depending on your feature set. In an ideal world, there would be a separate endpoint and corresponding data stream connecting to the output of each digital downconverter (or whatever code you've got in the fpga) and likewise for the Tx path. Then there would be additional problems related to signaling between the FX2 and FPGA which packets were to/from each endpoint etc. There are no unused pins between the FX2 and FPGA that could be used for addressing the packets on the GPIF. We're out of pins on the FPGA. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
