GNU Radio on embedded systems

GNU Radio
1

Has anyone looked at GNU Radio on an embedded system seriously? I’ve
built it for an ARM processor and heard that the dial tone example
will work.

I’m particularly interested in using the python-less method
of connecting blocks. I understand that many of the GNU radio blocks
are written using floating point, but does the core gnu radio code
depend on good floating point performance?

Philip

2

On 2/24/08, Philip B. [email protected] wrote:

I’m particularly interested in using the python-less method
of connecting blocks. I understand that many of the GNU radio blocks
are written using floating point, but does the core gnu radio code
depend on good floating point performance?

The GNU Radio runtime does not have any DSP floating point
dependencies, though the use of floating point is scattered throughout
for routine calculations. You’d need a co-processor or software
emulation to handle this.

That being said, the majority of existing signal processing blocks are
written to work with single-precision floating point; you’d have to
write your own fixed-point stuff.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

3

Philip B. wrote:

Has anyone looked at GNU Radio on an embedded system seriously? I’ve
built it for an ARM processor and heard that the dial tone example
will work.

I’m particularly interested in using the python-less method
of connecting blocks. I understand that many of the GNU radio blocks
are written using floating point,
Yes, allmost all of them depend heavely on floating point performance.
Floating point performance, memory speed and USB-throughput are the main
bottlenecks for gnuradio.
You could rewite some of the blocks in fixed-point, but then you loose
much dynamic range and need very high fixed-point performance.
I know of good performing Software Defined Radio platforms using an ARM
processor but they all have a high-performance DSP processor attached to
or integrated into the ARM processor.

but does the core gnu radio code
depend on good floating point performance?
Depends on what you consider “the core gnu radio code”.
The flowgraph and flowgraph-scheduler do not depend on floating point
performance.
But things like the spectrum display (fft-sink), all
modulation/demodulation and all the filter blocks do,

Martin

4

On Sun, Feb 24, 2008 at 05:54:08AM -0500, Philip B. wrote:

Has anyone looked at GNU Radio on an embedded system seriously? I’ve
built it for an ARM processor and heard that the dial tone example
will work.

I’m particularly interested in using the python-less method
of connecting blocks. I understand that many of the GNU radio blocks
are written using floating point, but does the core gnu radio code
depend on good floating point performance?

Philip

The core doesn’t have much floating point in it.

Eric

5

On Tue, Feb 26, 2008 at 08:53:26AM -0500, Philip B. wrote:

On Mon, Feb 25, 2008 at 4:54 PM, Eric B. [email protected] wrote:

On Sun, Feb 24, 2008 at 05:54:08AM -0500, Philip B. wrote:

The core doesn’t have much floating point in it.

What do you mean by core?

From your question, it sounded like you knew that pretty much all the
DSP is floating point. Thus my answer was referring to the non-DSP
portions of the code, mostly contained in lib/runtime.

extensions, wMMX, DSP comprocessors, etc). The turning off
compilation of the floating point structures.

If you want to use fixed point, then yes, you’ll need to code up a
whole set of fixed-point blocks. My life’s too short for that :wink:

If the new architecture had floating point, but it was dog slow, then
you wouldn’t need to turn them off, just refrain from using them.

I also see that gnu radio implements each filter several different
ways, depending on the input/output/tap data types. Why doesn’t gnu
radio use some kind of adaptive typing so you can have one block
process many data types?

There are certain cases where this would be possible if we hauled
around more type info for the input and output signatures. Since in
general the i/o types can be any plain-old-data (POD) or aggregate of
POD, this was more work that I wanted to take on. The only thing we
do haul around is the sizeof of the item type, but clearly that’s
insufficient for automatic inference (sizeof(float) == sizeof(int32_t)).

Also, there are cases such as filters with complex in, complex out,
where we’d also have to be looking at the tap types to figure out what
to instantiate. In addition, you may want to explicitly choose a dot
product vs FFT implementation of FIR’s etc.

Hopefully this makes sense, I did most of this thinking on the plane
back from FOSDEM with a nasty head cold.

Yes.

Eric

6

On Mon, Feb 25, 2008 at 4:54 PM, Eric B. [email protected] wrote:

On Sun, Feb 24, 2008 at 05:54:08AM -0500, Philip B. wrote:

The core doesn’t have much floating point in it.

What do you mean by core? The gnuradio-core directory src/lib
directory contains directories that contain signal processing code,
such as filter, and a directory , src/runtime, that contains the basic
component “framework” classes that handle block creation and
connection. The code in src/runtime does not appear to have any FPU
dependencies.

It seems that a serious effort to build gnu-radio for a new processor
would involve adding new filters that operate on a fixed point
quantity and optimized for specific instruction sets (ARM dsp
extensions, wMMX, DSP comprocessors, etc). The turning off
compilation of the floating point structures.

I also see that gnu radio implements each filter several different
ways, depending on the input/output/tap data types. Why doesn’t gnu
radio use some kind of adaptive typing so you can have one block
process many data types?

Hopefully this makes sense, I did most of this thinking on the plane
back from FOSDEM with a nasty head cold.

Philip