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

[Anderson, Douglas J.]

Yeah the dict idea was kind of what I was going for with the pairs (in pseudo 
code)

tuple(
  "command",
  pair("param1", val1),
  pair("param2", val2),
  ... 
)

It feels intuitive because it maps pretty well to the function call 
"command(param1=val1, param2=val2)", and it works with the current state of PMT.

The only downside is it's kind of icky to parse, but I'm not sure if having a 
dedicated dict type would ease that any.

-Doug

________________________________________
From: Martin Braun address@hidden
Sent: Tuesday, March 24, 2015 1:50 PM
To: Anderson, Douglas J.; address@hidden
Subject: Re: [Discuss-gnuradio] passing USRP source block shared pointer 
through SWIG

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
>