Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG

[Martin Braun]

On 24.03.2015 12:10, Anderson, Douglas J. wrote:
> [...]
> I actually considered implementing the lo_offset message code myself
> and then doing a pull request, but I just couldn't think of a good
> way to match the flexibility of a tune_request struct within the
> confines of a single pmt message.

Hey Doug, thanks for the feedback. This is exactly the kind of issues 
I'm interesting in.

> I wonder if there's a way for the message interface to accept a
> message formatted like this and then construct a tune_request from
> it?

As you say, not yet -- but we're still figuring this out, and sending 
tune requests is indeed very useful.

This whole concept of sending PMT commands is something that we want to 
get right. I could imagine something like this:

('command', 'arg1', 'arg2', ....)

Then, all tune request arguments would be just in there.

What we have right now for UHD is:

('command', 'arg1' [, 'channel #'])

...which is kind of similar.

Something else I'd like to have in the commands is a timestamp. This 
would be invalid for tags, but for PMT messages it would be fine.

Maybe we want command dicts? So you can have the command name as a 
field, and then all the arguments as key/value pairs.... but I want to 
not rush off and do my own thing there.
We already had issues when Tom & I came up with different formats for 
PMTs between the QT Freq Sink the UHD Source.

Cheers,
M

> > > > command = pmt.make_tuple(
> ...   pmt.intern("tune_request"), ...   pmt.cons(pmt.intern("freq"),
> pmt.from_double(900e6)), ...   pmt.cons(pmt.intern("lo_offset"),
> pmt.from_double(5e6)) ...   )
>
> -Doug
>
> ________________________________________ From:
> address@hidden
> address@hidden on
> behalf of Martin Braun address@hidden Sent: Monday, March
> 23, 2015 12:58 PM To: address@hidden Subject: Re:
> [Discuss-gnuradio] passing USRP source block shared pointer through
> SWIG
>
> You should easily be able to pass a basic_block sptr and then
> dynamic-cast it in your block.
>
> What you're trying to do is not recommended procedure, although I
> can see how it's necessary at times. Can you tell us what you're
> trying to do? We've been working on making the message ports more
> useful, which should hopefully take care of most issues.
>
> M
>
> On 23.03.2015 10:13, Anderson, Douglas J. wrote:
> > Hi all,
> >
> > I'm looking into the possibility of passing the <gr_block gr uhd
> > usrp source (0)> object from Python into a C++ out of tree module.
> > In my module, I have:
> >
> > controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr
> > usrp, [...])
> >
> > I get a TypeError when I instantiate the block. It seems like the
> > object created in Python is not a proxy for the sptr, and I can't
> > figure out quite how to get access to the sptr from Python.
> >
> > I've tried both of the alternatives to passing back in the sptr:
> > I've tried sending commands to the USRP via message passing
> > interface, but only freq and gain are implemented. At the very
> > least I need the full tune_request capability.
> >
> > I've also tried making that call with fevall_dd, but it's a
> > blocking call and it's too slow for my application. I could maybe
> > spawn that call in its own thread so it doesn't block, but I think
> > passing the shared pointer back is the cleaner and more correct
> > solution.
> >
> > So, how hard is this going to be? SWIG 2.0 supports boost's shared
> > pointer. I'm wondering if it'd just be a few extra lines in
> > GR_SWIG_BLOCK_MAGIC2to expose it, or am I kidding myself?
> >
> > http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr
> >
> > Thanks in advance, -Doug
> >
> >
> > _______________________________________________ Discuss-gnuradio
> > mailing list address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio