discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] M-block integration status


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] M-block integration status
Date: Thu, 7 Jan 2010 11:29:40 -0800
User-agent: Mutt/1.5.20 (2009-08-17)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]