Re: [Discuss-gnuradio] writing a c++ block that can access other blocks

[Alexandru Csete]

On Sun, May 22, 2011 at 11:37 PM, Brett L. Trotter <address@hidden> wrote:
> Follow up to self here- can anyone confirm whether I'm understanding
> this right?
>
> Looks like gr_edge_vector_t is a shared/static vector with all the edges
>
> Say I take this guy from gr_hier_block2_detail and modify it:
>
>  gr_edge_vector_t edges, tmp = d_fg->edges();
>  gr_edge_vector_t::iterator p;
>  for (p = tmp.begin(); p != tmp.end(); p++) {
>    if ((*p).src().block() == block || (*p).dst().block() == block) {
>      edges.push_back(*p);
>
>      if (GR_HIER_BLOCK2_DETAIL_DEBUG)
>        std::cout << "disconnect: block found in edge " << (*p) <<
> std::endl;
>    }
>  }
>
>
> so that it tests to see if the block is an instance of a usrp/usrp2
> block? Would that do? Ultimately I can assume there'll only be one usrp
> connected in my application, and through the one (be it source or sink)
> i can get to the dboard iface for either card (rx or tx) and manipulate io?
>
> Assuming the above is sound, is there any potential for harm in messing
> with things this way?
>
> And taking my original goal a step further for the sake of discussion,
> what if instead of an AGC I just wanted a block that gives a handle to
> the gain controls. Does GnuRadio have any facility for blocks that
> aren't really part of the flowgraph in terms of moving data, but just
> provide an instance of some sort of control?
>

Hi Brett,

Maybe I misunderstand what you are trying to do, but if you wish to
access the public methods of a USRP source block from within the work
method of another block that you write yourself, you can make the
constructor of your custom block so that it takes a reference to the
USRP object as a parameter and stores it internally, no?

Alex