Greetings All, Wow, I'm glad this has generated so much conversation. Thanks to everyone who has chimed in.
To Rick M, one of the things that attracted me to the BBB was that it has several available UARTS, but I also need things to run in a deterministic fashion since I need to control an array of servos and updating needs to happen 128 times a second, which means a several dozen byte packet going out that frequently. After reading through a bit more in the TRM about the PRU UART, I don't think a PRU UART will be feasible since it looks like they top out at around 300Kbs, and I need a megabit. I'm hoping things will be sufficiently deterministic since I'm running bare metal, and will drive the update loop with a timer interrupt and have the UART just feed things out as fast as the line will consume it. I know things will run more slowly if I don't use caching, but if I disable caching, does that eliminate any pipelining? I'm a noob when it comes to pipelining and caching, since I've only ever hacked on AVR microcontrollers and a Cortex M3, where those weren't considerations. I'm a line of business programmer in my day job :(. Matthijs, does EDMA offer that big a performance boost? Most of my background up to this point has been just coding things for handling hardware and timer interrupts and UART communication. I'm an extreme noob when it comes to the more involved hardware stuff like DMA. Does going from the PRU to DDR pass over the L3 interconnect whether it's DMA or regular DWORD by DWORD assignment? I'm figuring this will have to pump 9 MB a second to DDR, but with each write being a DWORD, this should only be one write every 455 clock cycles for the main core (assuming my math is correct). I have to admit, my head is swimming with some of what you wrote, so I definitely need to crack the books harder. If you know of any good references on MMUs, caching, and pipelining for beginners, let me know (I also need to educate myself more on kernel programming). I just imagine there has to be some good way to get good throughput from the PRUs to the rest of the system, otherwise the PRUs wouldn't be very useful to the rest of the system, but again, I may just be naïve. In the meantime, right now I'm just finishing getting my development environment set up for everything, since I'm using GCC and am using Eclipse for my IDE (up til now while learning my way around Starterware and the PRU tools, I've just been using notepad and the command line >_<). I've got it set up now to build the PRU code, convert it to C header files, and include it in my main code, which it can compile for the final bin and use memcpy to load and start the PRU at run time (primitive, but it works for my purposed right now). Now I'm going to start writing code to start trying to read the camera, and I'll report back my results. Maybe I'll eventually take the dive into Linux (I've waded in until this point). Thanks, again to everyone! On Sunday, June 14, 2015 at 7:36:46 AM UTC-4, Matthijs van Duin wrote: > On Wednesday, 10 June 2015 20:03:22 UTC+2, Charles Steinkuehler wrote: >> >> In addition to the other thread, I'd suggest looking at the >> BeagleLogic code. It's possible to move _large_ amounts of data >> through the PRU to the DRAM, but it requires some finesse. >> > > My first intuition would be using EDMA. > > > On Thursday, 26 March 2015 23:51:02 UTC+1, Charles Steinkuehler wrote: >> >> 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). >> > > Mapping the memory as uncacheable and using appropriate barriers suffices > (privilege is not needed, though typically baremetal code tends to run > privileged anyway). > > > 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. > > > Well in a baremetal application nothing is "already mapped". In fact an > issue here is that the PRU memory space resides within the same 1MB section > as peripherals, so if both are accessed from the A8 you'd need to set up a > page table for that section to make PRU memory space normal uncacheable > while making the peripheral space device-type. (Well, you don't *have* to, > but if you care about performance...) > > I do agree with having the PRUs stick to PRU memory as much as possible. > > >> 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. >> > > I'm pretty sure that ARM atomic bus transactions (neither the old locked > SWP nor the newer load/store-exclusive) will not accomplish anything > useful, if they get anywhere beyond the CPU boundary at all. > > TI is however referring to the hwspinlock peripheral which (along with the > mailbox peripheral) is specifically intended for inter-core > synchronization. I personally would not be eager to use hwspinlock though. > > I'd also try to go for unidirectional messaging like you're saying. The > mailbox peripheral looks quite reasonable for inter-core notification, > especially if this is infrequent and you want to avoid polling, though I > think you also may be able to do that purely with the rather elaborate > PRUSS interrupt controller. > > When writing from the A8 to uncacheable memory, do remember to finish off > with a memory barrier instruction since the A8 is allowed to (and *does*) > buffer writes indefinitely otherwise. > -- 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.
