[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] passing USRP source block shared pointer through
From: |
Anderson, Douglas J. |
Subject: |
Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG |
Date: |
Tue, 24 Mar 2015 20:18:12 +0000 |
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
>