Le jeudi 10 septembre 2015 11:50:32 UTC-3, William Hermans a écrit : > > *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.* > > > Do whatever makes you happy as far as fixing your problem. But know that > "professionalism" has nothing to do with programming. There are ways to do > somethings, and ways not to. > Nice and objective advice, I like it. In fact, the interrupt system works great to signal new data to be exchanged by the two PRUs, there are just the PRUs registers, no memory cache, everything completes in one pru cycle... a predictable word. I was lured to think that the same would happen to sync data between the PRU and the ARM. Now I see that when I wrote "professional approach", even stating that I am not a programmer, it may sounded offensive. So I ask, anyone who may felt uncomfortable, please forgive me. That was not my intention.
> > It is far more troubling to leave data variables uncleared once done with > them, and not use memory use synchronization. As these can promote hard to > nail down problems, as you're observing. > > Anyway, stop worrying about professional and what you *think* is > professional, and focus on the things that are actually important. > Thank you very much. I will re-implement the code with this kind of flagging... maybe it is the right time to dive into some posix threads reading. > > > On Thu, Sep 10, 2015 at 6:20 AM, Charles Steinkuehler < > [email protected] <javascript:>> wrote: > >> 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] <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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
