|
From: | M. Ranganathan |
Subject: | Re: [Discuss-gnuradio] Accessing the uhd_usrp object |
Date: | Thu, 14 Nov 2013 12:57:15 -0500 |
Hi,
First: Please pay attention and reply to the list and not to me personally.
What I think is that I wouldn't call that an improvement at all. IMHO
> A suggested "improvement" to the gnuradio code base (let me know what you
> think) :
> Please keep such objects in a globally visible list (I can provide a diff if there is interest) so that applications such as mine can access them. UHD > sources and sinks are likely to be quite static as are indeed most gr blocks I would suspect.
It's a horrible design ...
Wait what ? Passing the pointer cleanly between blocks is "messy",
>> You'll have to give the instanciated uhd source block as an argument
>> of your custom block constructor and play with SWIG to make the Python
>> object be converted back to a C++ smart pointer. Have fun.
>
> It sounds quite messy and hence I had to ask this list if there was a better
> way.
but polluting the global application namespace is "clean" ??? I think
we have radically different idea of what's good design and what's not
...
If I'm not mistaken, you can control the UHD source / sink with
> I am open to any ideas. I could of course modify the gnuradio source code
> to export a global pointer but I'd love it if I could leave the core source
> code alone.
message passing to change the frequency. Then your MAC just has a msg
output port connecting to the uhd message input port to control it.
Cheers,
Sylvain
[Prev in Thread] | Current Thread | [Next in Thread] |