On Wed, Mar 28, 2007 at 07:37:43PM -0400, George Nychis wrote:
>
>
> Eric Blossom wrote:
> >The basic idea is that there is a small piece of code that knows about
> >both abstractions and how to bridge between them.
> That seems like the best approach.
>
> >Yes. One daemon.
> *clicks the check box*
>
> So this daemon will be allocating the USB channels with the different ports
> connected to it? Basically what we talked about on the phone earlier...
> the methods described in:
> http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb-host
Yes.
Assume for sake of discussion that there's a mblock called
"usrp_usb_daemon" with 8 externally visible ports:
rx0
rx1
rx2
rx3
tx0
tx1
tx2
tx3
This is probably overkill, but hey, it's only a data structure...
For now, ignore the fact that the daemon will be running in another
address space. We'll sort that out later. Assume that you've got a
application (top level mblock) that contains an mblock based
output generator with a single output port which is connected to
the usrp_usb_daemon port "tx2" (which of the tx ports it's attached
to is arbitrary. If we ever implement "replicated ports", there will
two ports, rx and tx, each of which are replicated).
top-block (contains these two blocks):
"out" "tx2"
output generator <------------------> usrp_usb_daemon
> Writing an m-block, I do not want to worry about this, I am kicking my
> packets off to the daemon, who will decide what channels to allocate and
> such?
In real life there's probably another block or two in front of the
usrp_usb_daemon that handles this kind of stuff. This would include
the "tuning/control interface" etc. In that case, the dumb signal
generator would just send packets containing sample to be transmitted.
top-block:
application
control block
GUI, whatever
^
| cs
|
|
samples |
| cs (control/status port "tune", "interp" ...)
out in v out tx1
sig_gen<--------> smart usrp front end <---------> usrp_usb_daemon
Also, we may want to compose the "smart usrp front end" and the
usrp_usb_daemon, and split the control from the data ports. Let's make
something work, then we can revisit this when we've got some experience.
> - George
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
