Greetings Charles, Does the PRU stall when writing to memory outside of the PRU address space? I am working on interfacing a cheap camera to the PRU and want to have it write to a 640 x 480 buffer. So the PRU will only ever write to the buffer, and the ARM core will only ever read the buffer, so I don't see contention being an issue, but the amount of space I will need is bigger than what all the PRU memory combined offers so I definitely need to use DDR. My concern is that the PRU won't be able to write the data from the camera out fast enough, as there will be 8 parallel bits coming in every cycle at 12Mhz. I can shift 4 bytes in at a time and write it out DWORD at a time (which I guess would make the best use of the bus), but that is still a 3Mhz pace. Should the OCP bus be able to handle this? Any info appreciated.
Thanks, Bill Merryman On Thursday, March 26, 2015 at 6:51:02 PM UTC-4, Charles Steinkuehler wrote: > 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] <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.
