Hey Philip, nice to have you back.

On Mon, Aug 11, 2014 at 10:06 AM, Philip Balister <[email protected]>
wrote:

> I doubt depending on contiguous memory will ever work for GNU Radio.
> I've heard a lot of talk about changing the guts of GNU Radio, but no
> real action. Especially given GNU Radios dependence on double mapped
> buffering to handle wrap around.
>

What lead me to believe this would work was a little test that I ran. I
basically had two blocks print their virtual address, the block on the left
printed the write_pointer, block on right printed the read_pointer. From
looking at the buffer QA tests, the write_pointer and read_pointer point to
the buffers. What I observed was a giant buffer that contained three
buffers inside it. So GNU Radio would write to one of the buffers during
one cycle then move on to the next the next cycle until it wraps around
after the third cycle. When it wraps around it starts at a different
starting address for whatever reason but it is predictable. I suppose
changing this behavior to actually use the same start addresses for each
buffer would help.

On Mon, Aug 11, 2014 at 10:06 AM, Philip Balister <[email protected]>
wrote:

> I understand why TI drives you towards the CMEM driver, but that is a
> lousy long term plan. They are just reusing code from prior generations
> of drivers. And I do want to see something work so we can evaluate the
> hard IP based GNU Radio block. My concern with your wording is that
> people might think depending contiguous memory buffers is a good idea.
>

I can't use the CMEM driver since its GPLv2. I planned to write a much
simpler driver that just allocates memory in the desired physical address
which would be in some sort of shared memory. I think having the GNU Radio
buffer described above in a known physical shared memory location can make
the coprocessor interaction much easier since the coprocessor not having an
MMU can interact with the buffer directly.
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to