Re: [Discuss-gnuradio] Porting new hardware to GNURadio

[Getz, Robin]

On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered:
> On Thu, Apr 26, 2012 at 07:38, Getz, Robin <address@hidden> wrote:
> > Is there a "golden" reference to look at? (I assume
> > gr-howto-write-a-block-3.6.0.tar.gz
> > should have everything we need?)
>
> This will give you the "canonical" format for writing your own
> out-of-tree installable GNU Radio blocks.

And what is preferred? I always think in-tree is better - but that's just me.

> A hardware source block would have no input ports, one or more output
> ports for whatever streams your device generates, and a work function 
> that wraps calls to your existing sample-based I/O library for your
> device.  The main purpose of the work function would be to retrieve
> samples from the device and put them into the block output buffer, and
> some housekeeping to tell the GNU Radio runtime what you've done.

What is the widest band device (MSPS) that GNURadio can keep up with in real 
time? With this card - we are limited in memory bandwidth (vs a desktop), and 
Cortex A9 isn't bad - but it's no Intel CPU in terms of floating point 
performance...

Who actually manages the location of the buffer? If GNURadio mmaps the 
location (rather than malloc), it will save a memcpy in the work function.

What's the format that GNURadio wants (16-bit fixed? float? other?) We can 
make the format converter in the HDL, to decrease the load on the processor.

> You'd also need write any needed setter/getter functions to perform
> configuration of your source block either at initialization or during
> runtime.

There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC 
sample rates, sync, MIMO config, etc) - I'm assuming some of those 
configuration knobs are exposed to the python interface in a standard manner 
across hardware?

> > ...although it appears we need to extend our FSF copyright assignments
> > before we get too busy.
>
> This isn't needed to develop your own distributed GNU Radio blocks;
> you only need comply with the GPLv3 license terms of GNU Radio.

Right - but I would think that it would be better to have things in tree?

With all the FSF packages that we have contributed to in the past (gcc, 
binutils, gdb, etc) without a FSF copyright assignment - the package 
maintainer would not accept patches. I believe that is what is indicated 
here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment

Thanks
-Robin