On 9/10/2015 7:07 AM, Carlos Novaes wrote:
> I think I got tour point here. I used the signal/interruption
> system to sync between arm and pru, as it seens to me a more
> professional approach (I am not a programmer anyway...) than keep
> reading a status flag on the shared memory. But It seems that the
> pru functions to write to the shared ram region are not blocking
> and will return even if the data was not actually written into RAM.

Writes will always complete, but it's possible to see updates happen
out of order due to hardware or compiler optimizations (that's what
memory fences are for).

You also don't mention if "shared ram" is the PRU shared memory region
or a chunk carved out of SDRAM.  The data will always be written, but
visibility rules (especially on the ARM side) will depend on the
specific code you write, the memory region flags (cache-able, I/O
region, etc), any memory barriers used, etc.

You'll have a much easier time using the PRU shared memory region if
you're not already.

>  I will try to set some flag so signal that a chunck of data was
> already processed and will see how it performs. Another thing to
> note is that each time new data is read by ARM, another chunck of
> data is written to the same shared memory, just in a different
> location. This could cause the bus to saturate at some conditions?

The description of your code so far hasn't sounded much like a
standard ring buffer.  Writing lockless multi-threaded code is
non-trivial, and there are lots of ways to mess things up.  I suggest
you either use a proper ring buffer (if you don't want dropped
samples), or a proper req/ack mechanism if you're just trying to get a
single value at a time across the PRU<>ARM boundary.

If you want more specific help, post a link to some code for review.

-- 
Charles Steinkuehler
[email protected]

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to