Pretty much all of the memory is shared, in that both the ARM core and the BBB can see it.
Using the DDR system memory is problematic, however. It is both more cumbersome to use on the PRU side (accessed via the interconnect bus it stalls the PRU while reading), and on the ARM side you won't ever see any changes unless you're careful about your cache management (typically using kernel-mode code and the same sort of memory semantics required when doing DMA transactions). I'd recommend just using the PRU data memory space for anything like semaphores or mailboxes. The memory is already mapped with the proper access flags to avoid ARM side caching issues, and the PRUs can access the memory without stalling. The only real reason to use anything but the PRU shared memory is if you're data set is larger than the 8K/12K RAMs will support. I looked at your TI post, but it doesn't make much sense to me. I'm not very familiar with starterware, or with the spinlock register you refer to. I can say that the ARM atomic bus transactions are unlikely to work properly between the PRU and the ARM if you're using the PRU shared memory, but there are many other synchronizing constructs you can use. The mechanisms I've used in my code rely on unidirectional atomic access, which works well. The ARM writes values into the PRU shared memory which the PRU reads, and the PRU writes to *DIFFERENT* locations which the ARM side reads. With only a single writer for each memory address, there is no need for an atomic "read-modify-write" as needed for a traditional spinlock. It's possible to directly build lockless work queues and req/ack handshakes out of this sort of primitive, and if you really want a spinlock, you could build it on top of req/ack. On 3/26/2015 5:35 PM, BryanB wrote: > Thanks for your reply Charles. My question was not well formulated. > I have an understanding of the theory of mutual exclusion. However, > applying the theory using starterware on the beaglebone black is where I am > making slow progress. > ANY examples would be useful of any method. One simple method I have used > in the past is spinlocks and shared memory. But I haven't been able to get > that working yet on the BBB with Starterware. > I posted a more detailed question on the TI E2E Starterware forum but > haven't received any replies as yet (perhaps it was also a badly formulated > question!). > https://e2e.ti.com/support/embedded/starterware/f/790/t/410442 > Thanks again. > > On Friday, 27 March 2015 00:15:39 UTC+11, Charles Steinkuehler wrote: >> >> On 3/26/2015 2:38 AM, BryanB wrote: >>> >>> Hi Satz, >>> Did you ever make any progress with your questions? >>> >>> I have successfully used Starterware on the BBB and a TI PRU-Cape with >> its >>> supporting software to load and run PRU program examples. >>> However, I haven't found any examples on communicating between the ARM >> and >>> the PRUs via shared memory. Have you? >>> I did get a simple transfer to work but am not sure about ensuring >> mutual >>> exclusion or the best way to set up the shared memory. >> >> There is no single correct or "best" way to implement communications >> between the ARM core and the two PRUs. This is a standard problem in >> all multiple core machines, and you will find a lot of material with a >> quick Google search. Depending on your application you may want to use >> things like mailbox registers, lockless queues, interrupt signaling, >> req/ack handshakes, etc. >> >> -- >> Charles Steinkuehler >> [email protected] <javascript:> >> > -- 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.
