have a look at the feval class [1]; it's a way to call python code from
C++ land, and vice versa.


Be /ver//y/ careful about multithreading – all the GNU Radio blocks run
in their own thread, so does the GNU Radio scheduler, and just executing
python while python is executing might have interesting effects!


My approach would probably be to write a Python sync block with 0 in and
0 stream outputs,  and connect that to the blocks you want to control
with message passing as far as possible (UHD source has a command
message interface, so this would work nicely), and call the python
top_block's set_variable() methods only when impossible to avoid. In
fact, things can be pretty easy: The ZeroMQ message sources can accept
zeromq messages, and you could directly connect them to the message
control ports of the blocks, so no need to write your own GNU Radio
blocks at all; just use #include <pmt/pmt.h>/pmt::pmt_t and ZeroMQ in
your C++ code to send messages directly across network/IPC/intra-process
queues to your Flow graph.


Best regards,

Marcus


[1] http://gnuradio.org/doc/doxygen/classgr_1_1feval.html


On 19.08.2016 14:07, Pranav Padalkar wrote:
>
> Hi Sebastian,
>
>
> Thanks for your reply. In the meanwhile I was going through some
> documents on embedding Python in C++. I liked the idea of having a
> python code embedded in my client c++ code. But I think access data
> variables from the gnuradio code (for eg centre freq, bw, gain, etc)
> will be difficult. Because I want to set them from my client c++ code.
> I am still searching for other options, but so far python embedding
> seems good. Will let you know how it works.
>
>
> If others have any other options, please let me know.
>
>
> Thanks!
>
> Pranav
>
>
> ------------------------------------------------------------------------
> *From:* Koslowski, Sebastian (CEL) <sebastian.koslow...@kit.edu>
> *Sent:* Friday, August 19, 2016 1:15 PM
> *To:* Pranav Padalkar; discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Using GRC generated python code
> inside a C++ code
>  
> Well, there a number of options. Given your description its hard to
> say which one is best.
> Aside from maintainability and flexibility of the system, it really
> depends on the required interaction between the components.
> You could
>     - re-implement the fg in C++.
>     - create Python bindings for your C++ client (e.g. with swig) and
> do the integration/coupling in Python (outside of the fg)
>     - embed Python in your C++ client
> (https://docs.python.org/2/extending/embedding.html)
>     - simply run the Python interpreter as a sub-process if the C++ client
>
> If you choose 2, 3 or anything not the list let me know how it worked
> out =)
>
> Sebastian
>
>
> On 08/19/2016 10:02 AM, Pranav Padalkar wrote:
>>
>> Hello,
>>
>>
>> I have a GRC generated python code. I also wrote a server-client code
>> in C++. I want to implement the client-code along with the GNU python
>> code. The essence is that I want to a run a client C++ code, which
>> will call the python code in a thread and start the USRP to
>> receive/transmit data, and continue performing it's own process in
>> another thread. I am not sure how I could go about this. I also
>> considered implementing the client C++ code as module in GNU radio
>> and use it in the flow graph. But I think that's not how a client
>> background code should run.
>>
>>
>> Any thoughts on this matter would be helpful. Thanks in advance.
>>
>>
>> Best Regards,
>>
>> Pranav Padalkar
>> Fraunhofer-Institut für Eingebettete Systeme und
>> Kommunikationstechnik ESK
>>  
>> Hansastraße 32 | 80686 München
>> Telefon, Fax: +49 89 547088-0 | +49 89 547088-220
>> E-Mail: pranav.padal...@esk.fraunhofer.de
>> <mailto:pranav.padal...@esk.fraunhofer.de>
>> Internet:
>> http://www.esk.fraunhofer.de <http://www.esk.fraunhofer.de/>
>> http://www.twitter.com/FraunhoferESK
>> http://www.facebook.com/FraunhoferESK
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to