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

[Miklos Maroti]

Hi Ron,

I want this operating at 200 Ms/sec, so would like to avoid copying if
possible. I will look into other alternatives. Thanks, once again!

Miklos

On Tue, May 30, 2017 at 3:53 PM, Ron Economos <address@hidden> wrote:
> 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 <address@hidden> 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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio