On Mon, Jan 04, 2010 at 03:49:38PM +0100, Patrik E. 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
Re: [Discuss-gnuradio] extract timestamp data / "The Plan"
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 E.
Thanks for your question, and if you’ve got more, please ask away!
Eric