discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Using GnuRadio API from C++


From: Terry Barnaby
Subject: Re: [Discuss-gnuradio] Using GnuRadio API from C++
Date: Mon, 03 Oct 2005 14:58:36 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.3.2

Eric Blossom wrote:
On Fri, Sep 30, 2005 at 09:34:47AM +0100, Terry Barnaby wrote:

Hi,

We are looking at using GnuRadio for a data processing project.
The code will be developed in C++.
We have played around with GnuRadio using the Python bindings and
it seems to do the job we require quite well. However, we would
need to use the GnuRadio data processing directly from C++.
There does not seem to be a C++ API that matches the Python API,
for example there does not appear to be a "flow_graph" class
to connect and run a processing stream.


That's correct.  It was *much* easier to implement the flow_graph
class as well as much of the other code in Python (e.g., policy stuff,
hierarchical blocks).  This code isn't performance critical, so
there's no killer disadvantage to using Python.  The big win is that
Python allows you to operate at a *much* higher level of abstraction
than C++.  You can concentrate on the problem at hand instead of
trying to figure out how to jam your solution down into C++.


Is there a recommended way to use the GnuRadio library from C++ ?


Sorry.  Many of the bits and pieces would be usable, but the high
level stuff is written in Python.

Making GNU Radio run on an embedded system shouldn't be hard. I understand that Python runs under ucLinux, but haven't tried it
myself.  You ought to be able to pair down the total size by just not
installing portions of the python library (that are coded in Python of
course) that you don't need.

Other strategies that might work if you're deeply committed to C++,
are to interface your new C++ code to the python stuff using any of a
number of IPC mechanims: sockets, pipes, TCP/IP, shared memory, etc, etc.
Python handles all of those nicely.

What's your aversion to Python? RAM's cheap, even in an embedded world ;)

Eric

Hi Eric,

Thanks for the info.
I don't have an aversion to Python, we use it quite a lot. But our
current project involves production of a real-time 24/7 semi-embedded
system. It is good for ease of development, testing, installation and
maintainance to have small amounts of code and as few dependancies
on other sub-systems as possible. In this case Python adds a big
layer of complexity to the final system.
Physical RAM may be cheap but producing/maintaining a real-time system
that has a lot of code is not :)
I will have a look to see if we can use the lower-level 'C++' signal
processing classes in our system directly.

Cheers

Terry







reply via email to

[Prev in Thread] Current Thread [Next in Thread]