On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered: > On Thu, Apr 26, 2012 at 07:38, Getz, Robin <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
