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!