Hello all!
I want to write a block that can directly access the uhd_usrp_source.
This
block is a mac block hence it is up on the food chain and far away from
uhd_usrp_source in terms of its processing function. What is a good way
of
passing it a handle to the usrp_source ?
I can think of some hacks (such as a static global pointer where the
uhd_usrp_source C++ object registers itself) but it seems ugly to me to
take that route. Is there a better way to access global objects from
within
a block implementation.
Thanks in advance for any help.
Regards,
Ranga
Hi Ranga,
that’s what pointers are for, after all. Just do it! Thanks to the
make()-magic you basically always have a smart shared pointer instead of
an block object (unless you really try to break the system 
).
Just a quick note though: MAC is usually timing-relevant. Timed commands
might not work as you expect, so please be aware that calling
set_command_time on your source might break functionality since there is
no out-of-order execution.
Greetings,
Marcus
Marcus,
Thanks for your reply. What will the shared pointer be called. I see
stuff
like this in the code:
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)
Presumably, that generates a structure that is registered as a global
pointer. So in my mac, I want something like
extern …
At the risk of asking for too much help, can you give me some guidance
or
point me to a fragment of code somewhere that does this sort of thing.
Thanks,
Ranga
Marcus,
Looking around I don’t see where the pointer to the block is made
globally
visible. I am inclined to add some code to the make method to register
the
shared pointer in a global variable when the method is called. Since my
application has only a single USRP block (source and sink), there’s no
danger of overwriting something.
My problem is this:
I have python code that creates the blocks and strings them together
etc.
but I want to actually access the created block from c++ code (in the
mac
block implementation).
Let me know if I am seriously astray.
Thanks again for your help.
In GR 3.7, the shared pointer is usually blockname::sptr;
I can’t really point you to a very good example, but when you call
top_block.connect(src, sink) in C++, you’re giving it spointers 
As I said, whenever you make a block, you actually get a shared pointer
to that instance, and not the object itself.
Hi Ranga,
either you’re seriously astray or I don’t understand what you want.
This is C++ running on an operating system with segmentation. There are
no globally visibly objects, there is only calls to the operating
systems / IPC to communicate with other processes and objects that live
within your own process that you can directly address. Ok, there’s
shared memory, but you can’t move a uhd_source to shared pages; that
doesn’t make sense.
When you’re in the same process, it’s easy just to pass pointers around.
They are objects as everything else. Let’s assume you construct a
flowgraph like
top_block->connect(uhd_source, processing, mac, sink)
then you can just do
mac->set_uhd_src_pointer(uhd_source)
which would be something like
mymac::set_uhd_src_pointer(uhd_source::sptr src)
{
_uhd_src_sptr = src;
}
which enables you to just
_uhd_src_sptr->set_center_frequency(20000);
inside your class.
Greetings,
Marcus
Marcus,
Based on what you and others have replied, I think my “most elegant”
plan
of attack would be to toss the generated puthon glue code (which I
generated using grc-companion BTW) and do everything in C++ so I dont
have
to worry about the language interface at all.
This way, I will not need global shared pointers.
Thank you again for all the time you have spent responding to me.
Ranga
Hi,
Looking around I don’t see where the pointer to the block is made globally
visible.
No where.
There could be several UHD source/sink blocks, so nothing will be made
globally visible by GR.
I have python code that creates the blocks and strings them together etc.
but I want to actually access the created block from c++ code (in the mac
block implementation).
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.
Let me know if I am seriously astray.
You are. Whatever you need to do, there has to be a better way.
Cheers,
Sylvain
I am working on a dynamic spectrum mac where the MAC will reach out to a
TV
White space DB (and also potentially do spectrum sensing) and adjust the
centre frequency of the USRP periodically.
Thanks for your help!
Regards,
Ranga
On Thu, Nov 14, 2013 at 12:14 PM, Sylvain M. [email protected]
wrote:
Hi,
First: Please pay attention and reply to the list and not to me personally.
Mercy! That was an honest mistake. A thousand apologies.
It’s a horrible design …
I agree. If you notice I started off with that premise (i.e. that it was
a
hack).
Wait what ? Passing the pointer cleanly between blocks is “messy”,
If I’m not mistaken, you can control the UHD source / sink with
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.
I will look at the block again but I could not see that.
Thanks for taking the time to reply.
Regards,
Ranga
Hi,
First: Please pay attention and reply to the list and not to me
personally.
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.
What I think is that I wouldn’t call that an improvement at all. IMHO
It’s a horrible design …
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.
Wait what ? Passing the pointer cleanly between blocks is “messy”,
but polluting the global application namespace is “clean” ??? I think
we have radically different idea of what’s good design and what’s not
…
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.
If I’m not mistaken, you can control the UHD source / sink with
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