Here is something for you to look at Bill. http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/59975
Charles, and a couple other people talk some about cycles and how many cycles reading / writing takes to various addresses. Not sure this will answer your question thoroughly or not. One user suggests using PRU0 to write to the PRU shared RAM, while PRU1 takes this data, and writes it to DDR. Instead of using DMA. On Wed, Jun 10, 2015 at 7:55 AM, Bill M <[email protected]> wrote: > 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] >> > -- > 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. > -- 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.
