[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Proposed extensions for data networking
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Proposed extensions for data networking |
Date: |
Wed, 7 Jun 2006 18:48:50 -0700 |
User-agent: |
Mutt/1.5.9i |
On Wed, Jun 07, 2006 at 02:06:21PM -0400, Michael Dickens wrote:
>
> >>Why require m-blocks be the place where gr-graphs are called from?
> >
> >First off, nobody is forced to use the m-block stuff. All the old
> >stuff will continue to work just as it does now. That's part of the
> >reason for the strict separation.
>
> Ahhh .... now I think I'm understanding better. The m-block stuff is
> much like the USRP ... knows nothing of GNU Radio, works
> independently of GR, but is a module in the same way that gr-usrp and
> gr-audio-xxx are. The programming is entirely separate for the m-
> block module, can operate separately from the current GR, much like
> the USRP module can. gr-mblock would be the "glue" understanding how
> to operate gr-block's inside an m-block, and hence requires the
> gnuradio-core libraries and headers for functionality.
Yes.
> Does the mblock module require knowledge of the USRP?
No.
> Or will there be a mb-usrp module to handle that set of data transfers, much
> like
> there is a gr-usrp module for handling gr-block data transfers.
Yes. We may refactor gr-usrp if there's common non-GNU Radio stuff
that might want to get pushed back into usrp. The code that handles
endianness and packs and unpacks between the fixed point USB
representation and complex<float>'s comes to mind.
> So an mblock is provided with the packet and other meta-data to use
> as it sees fit. As the message makes its way through the m-block's
> connections / ports, the data is transformed / processed / parsed /
> etc... (see 4.8.4). There is no explicit "output" port(s), but
> rather these bi-directional ports which could be used as input-only
> or output-only. The data is transformed by creating new messages to
> pass around?
Yes.
> 4.8.3:
> "• requires persistence as the message is processed by the radio
> • may contain elements that change as the message is processed in the
> radio."
>
> If I read this, w/r.t. your comments before, then some messages must
> be kept around as they are processed (creating other messages, which
> also might need to be kept around: "persistence"), while others can
> have their internals changed during processing.
Yes.
> Also: An m-block can "contain" other m-blocks internally, or at least
> that's what I now believe. How are those internal m-blocks
> scheduled? Is there an internal "m-scheduler" which calls them in
> their correct order? Or does the encompassing m-block just "know" to
> call them in order and deals with this itself? Or some other way?
Composition of mblocks is for structural organization & complexity
management. It does not imply anything about scheduling. There is
one mblock scheduler that dispatches messages across all mblocks,
nested or not.
> >Note that in the BBN proposal there are no "graphs".
> >There are only mblocks, some of which contain other mblocks.
>
> Ok, yes, a semantic difference really. mblocks can be connected to
> other mblocks, internally and/or externally. Those connections must
> be checked somehow, whether the terminology is "graph" or
> "connection" or whatever. It must be verified that the connecting bi-
> directional ports are compatible (see 4.9.5 for that definition).
Agreed.
> So in 4.8.4 what is the "flow graph" as mentioned: "As a message
> makes its way through a flow graph, the data is transformed by the
> blocks along the way." Since this is generic, I don't think it
> applies specifically to the current gr_blocks and related flow-
> graph. If there is no m-graph, then those "flow-graph" references
> should be changed.
Agreed.
Eric