Le jeudi 10 septembre 2015 10:21:00 UTC-3, Charles Steinkuehler a écrit : > > 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). > I see
> > 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. > Yes, I am using it. The 12K region of ram shared between the two PRUs and that may be memory mapped for the ARM. > > > 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. > In fact, it is not exactly a standard ring buffer implementation. In fact there is just a region of memory, lets say 32 contiguous structures of 32 bytes. At the PRU side I got a "pointer" which is in fact just an index from 0 to 31, with a single increment at each new sample and wrapping around 32->0 This "pointer" is written to another region of the shared RAM and the ARM can read it. Also, the ARM has it own version of this same pointer, indicating the location of the previous processed sample and will increment it after receiving a interruption from the PRU. Usually, the two versions of this pointer will have the same index value, but if the ARM fails to process one or more samples, they will have different values. If they have different values, then the arm code will know that nothing can be done as response to the missed samples, but the old data may be (in fact they will be) useful to compute a more accurate response to the actual sample. > > If you want more specific help, post a link to some code for review. > The code is messy and some variable names are very unclear, but I will post it anyway, if someone is interested or willing to help/comment Thank you very much for your help and hints. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- 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.
