Re: [Discuss-gnuradio] scratch space in output buffer

AFAIK, there's no way to preserve the output buffer between
general_work() or work() calls. Are you that constrained with the amount
of memory your block can use? A few hundred samples is not very much. In
one of my DVB-T2 blocks, I have 786,432 bytes of static memory allocated.

https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbt2/dvbt2_freqinterleaver_cc_impl.h#L35

Ron

On 05/30/2017 01:42 PM, Miklos Maroti wrote:
> Hi Ron,
>
> Thanks for the quick response!
>
> On Tue, May 30, 2017 at 3:32 PM, Ron Economos <w6rz@comcast.net> wrote:
>> If you call set_output_multiple() in your block constructor, it will
>> guarantee the size of the output buffer.
> That would actually work (so I return exactly one block of items less
> than requested, and use the last slot for scratch space), although it
> will be inefficient for large scratch space size (I need a few hundred
> samples).
>
>> The scheduler won't touch it until you exit your block with:
>>
>> return noutput_items;
> No good, I would like my scratch place to be preserved across
> general_work calls, so return noutput_items will not be enough.
>
> Best,
> Miklos
>
>> Ron
>>
>>
>> On 05/30/2017 12:57 PM, Miklos Maroti wrote:
>>> Hi,
>>>
>>> I would like to use scratch space within the output buffer of a block,
>>> but not sure if I can rely on the scheduler not altering the content
>>> of those items in the output buffer that I have written to but have
>>> not made it available to downstream blocks within general_work. I know
>>> how blocks, forecast, general_work and history works, but I think my
>>> use case is not covered.
>>>
>>> A simple toy use case would be to implement a fir filter without the
>>> history call (I know that in this case history is better). Once a new
>>> sample is taken from the input you multiply that with an N-length
>>> kernel and add it to the output buffer and output only one item and
>>> zero out N-item ahead.
>>>
>>> Can I rely on the scheduler not to modify unproduced items (but of
>>> course within the limits of ninput_items)? Should I return 0 for
>>> forecast when there is not enough space in the output buffer? Would
>>> such a block be synchronous?
>>>
>>> Best,
>>> Miklos
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio