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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
