Dear All,
I have built a block that uses single input sample to produce a single
output sample. The weird thing that general_work in gr_block returns a
number around 4095, 4096. any interpretation or solution for this?
Thanks a lot.
Zohair
On Sat, Jun 05, 2010 at 02:23:21PM +0100, Zohair M. Abu Shaban wrote:
Dear All,
I have built a block that uses single input sample to produce a
single output sample. The weird thing that general_work in gr_block
returns a number around 4095, 4096. any interpretation or solution
for this?
First off, why do you think that this is a problem?
You block should be written such that it produces the number of output
items that is requested. It sounds like the block is doing that.
There are many 100’s of examples of blocks in the code base.
If you haven’t already, please read:
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html
It’s somewhat out of date, but the fundamentals are correct.
Eric
Hi Eric,
I have read what you recommended but still haven’t understood what the
significance of this number is. I have another block that generates a
vector of 4 elements and the noutput_items is almost 1/4 the number of
first block. Any further help please?
Thanks again,
Zohair
On Wed, Jun 09, 2010 at 11:57:24AM +0100, Zohair M. Abu Shaban wrote:
Hi Eric,
I have read what you recommended but still haven’t understood what
the significance of this number is. I have another block that
generates a vector of 4 elements and the noutput_items is almost 1/4
the number of first block. Any further help please?Thanks again,
Zohair
The numbers are choosen by the GNU Radio runtime system. They may
vary over time and are dependent on the amount of buffer space
allocated by the runtime and the rates of production upstream and
consumption downstream. The values are choosen by a heuristic
designed to optimized throughput.
If your block is properly written, it will respond appropriately to
any value of noutput_items.
I’m not sure that I’ve answered your real question. I suspect that
you may be somewhat unclear about the nature of the streaming data
flow model that’s used in GNU Radio.
Eric
OK Eric. from what you’ve said I can understand that we cannot control
noutput_items. All what we can do is return it from general_work(). It’s
solely for coordination issues and the runtime system takes control over
it.
Thanks.
Zoh
Eric B. wrote:
Thanks again,
–
View this message in context:
http://old.nabble.com/Why-does-general_work-return-large-number--tp28789377p28841275.html
Sent from the GnuRadio mailing list archive at Nabble.com.
But again, let’s go back to the howto_square example. What is the
significance of indexing the output pointer from 0 to noutput_items?
This
means we are generating and storing 4096 point at a time!
float *out = (float *) output_items[0];
for (int i = 0; i < noutput_items; i++){
out[i] = in[i] * in[i];
}
Zohair wrote:
Eric B. wrote:
Thanks again,
–
View this message in context:
http://old.nabble.com/Why-does-general_work-return-large-number--tp28789377p28843219.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Thu, Jun 10, 2010 at 06:35:18AM -0700, Zohair wrote:
But again, let’s go back to the howto_square example. What is the
significance of indexing the output pointer from 0 to noutput_items? This
means we are generating and storing 4096 point at a time!
float *out = (float *) output_items[0];
for (int i = 0; i < noutput_items; i++){
out[i] = in[i] * in[i];
}
Yes. So what? If we generated only a single output sample per call
to work, the entire system would run very much slower. As it’s coded,
it produces one output sample for each input sample, for any value of
noutput_items.
Eric, de K7GNU clear.
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.
al fayez
On Thu, Jun 10, 2010 at 07:07:35PM -0400, [email protected] wrote:
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.
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…)
al fayez
Eric
On 06/11/2010 04:15 PM, Eric B. wrote:
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.
Philip