Re: [Discuss-gnuradio] GNU Radio on embedded systems

[Eric Blossom]

On Tue, Feb 26, 2008 at 08:53:26AM -0500, Philip Balister wrote:
> On Mon, Feb 25, 2008 at 4:54 PM, Eric Blossom <address@hidden> wrote:
> >
> > On Sun, Feb 24, 2008 at 05:54:08AM -0500, Philip Balister 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.

> 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.

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 ;)

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