Hey Bill, If you're needing deterministic, and *if* you decide to run Linux( or maybe just experiment ), You can always look into Xenomai.
Now keep in mind that I have no hands on personally. But it could be as easy as writing a current image to sdcard, and apt-get install-ing one of the latest xenomai kernels. Followed by learning about Xenomai of course . . . something I've been wanting to do myself, but have no gotten around to. On Mon, Jun 15, 2015 at 7:33 AM, Bill M <[email protected]> wrote: > 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. > -- 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.
