|
From: | M. Ranganathan |
Subject: | Re: [Discuss-gnuradio] Accessing the uhd_usrp object |
Date: | Thu, 14 Nov 2013 11:54:04 -0500 |
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
On 14.11.2013 16:53, M. Ranganathan wrote:
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.
On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller <address@hidden> wrote:
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.
On 14.11.2013 15:39, M. Ranganathan wrote:
Thanks,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.extern ....Presumably, that generates a structure that is registered as a global pointer. So in my mac, I want something likeMarcus,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)
Ranga
On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller <address@hidden> wrote:
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
On 14.11.2013 01:26, M. Ranganathan wrote:
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
--
M. Ranganathan
_______________________________________________ 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
--
M. Ranganathan
--
M. Ranganathan
[Prev in Thread] | Current Thread | [Next in Thread] |