[Top][All Lists]

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

Re: [Discuss-gnuradio] Gnuradio/Beagleboard modifying flow graph buffer

From: Philip Balister
Subject: Re: [Discuss-gnuradio] Gnuradio/Beagleboard modifying flow graph buffer allocation
Date: Mon, 14 Jun 2010 11:02:32 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4

On 06/11/2010 04:15 PM, Eric Blossom wrote:
On Thu, Jun 10, 2010 at 07:07:35PM -0400, address@hidden wrote:

hi, I'm working on Gnuradio on the Beagleboard.  I've managed to
successfully integrate the DSP as a custom signal processing block
and I'm essentially using TI library based buffers to transimt data
between the GPP and DSP.  I'm trying to use pointers to copy data to
and from the DSP instead of doing direct memory copies as per Philip
Ballisters suggestion.  I'm familiar enough with the TI tool set to
do that but I'm not very familiar with GNU Radio's base architecture
to do the necessary changes and I was wondering if someone can help.

I basically need to allocate the data buffer through the TI toolset
API instead of the vector class in C++, is there a good way to
overide the buffer allocation in GNU Radio without "breaking" the
flowgraph?  thanks.

If you are trying to do an alternate allocation method for the buffers
that are passed to the work methods, that's a _substantial_ amount of
work in the GNU Radio runtime.

It's possible, but would require a deep understanding of the guts of
GNU Radio, and then would require a fine piece of design to come up
with something that accomplishes this without breaking anything or
touching a lot of code in the runtime.

The short term problem is can we get dsplink to use buffers passed to the block by gnuradio, without dsplink copying the buffer into some shared memory space. The OMAP3 DSP has a MMU, so it can do some clever things, but we are not sure if dsplink knows to use it.

Long term, a fully integrated gnuradio solution would be much better :)

Start your exploration in gnuradio-core/src/lib/runtime :-)

See in particular gr_buffer.{h,cc}, and all the code that calls it.

Before you even go there, what percentage of CPU cycles and/or memory
bandwidth is being consumed by the copying when running a "typical"
application?  (Measure twice, cut once, time be time...)

This is a case of premature optimization, but we do know that the memory bandwidth is one of the factors that will limit performance, so thinking about this up front is a good idea.


al fayez


Discuss-gnuradio mailing list

reply via email to

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