On Mon, Jan 04, 2010 at 03:49:38PM +0100, Patrik Eliardsson wrote: > Hi Folks,
> Now when the VRT implementation seems to be almost finished, We're getting there! > what is the status of the integration of m-block capabilities into > the gnu-radio? The functionalities described here > http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00319.html > are just what we are looking for. However, if we don't want to wait > too long, can this be achieved with m-blocks at the moment? What > functionality is missing in the m-blocks? Or has anyone solved this > in another way? m-blocks are deprecated, and no further development will be done on them. We have a two pronged approach to achieving similar (or related) functionality. In no particular order they are: (1) Designing and implementing a mechanism whereby blocks can embed isochronous metadata in a data stream, tied to specific sample indicies. The idea is that blocks can check or set key/value pairs over a range of sample indices. We expect the metadata for streams that originate from a VRT source to contain the VRT Timestamp at the appropriate sample index. The GR runtime will be extended such that existing blocks, which are naive about this feature, will transparently forward metadata from their inputs to their outputs. (2) Implement per-block message queues to asynchronously receive messages containing arbitrarily-typed payloads from other blocks, and process them. (The first phase of this is complete, but we haven't advertised the feature since we're lacking support in hier_blocks, a high-level way to wire everything together, and are missing documentation and examples). As part of this, GR block "work" methods can send asynchronous messages. When a block receives a message, its handle_msg(pmt::pmt_t msg) method is called. The runtime ensures that handle_msg is never called while the block is in "work" and vice-versa. That is, the runtime handles everything related to ensuring that this feature works reliably in a multi-threaded environment. Both of these are on my "short-list" of work to get done. I expect that both will be complete by the end of February. I want to make a couple of additional observations about async message passing (2). Async message passing allows for the creation of blocks which: * Have only streaming input and/or outputs (like today) * Have only async message passing (no streaming i/o) * Have both streaming input and/or outputs and have async message passing This gives us the possibility of easily bridging between the dataflow and message passing enviroments. We expect that many "MAC-like" features will be implemented using async message passing, while some PHY layer stuff will continue to be implemented using the data flow paradigm. Adding a msg_handler to existing blocks allows block parameters to be tweaked at runtime without fear of thread safety problems. We've been kicking around some ideas for a "middle layer" that supports getting and setting arbitrary attributes, in such a way that adding them to a block is as simple as filling in a small table. > Regards, > Patrik Eliardsson Thanks for your question, and if you've got more, please ask away! Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
