William, Charles, and Karl, I can't thank you enough for all of your input. My intention is to use a cheap OV7670 camera to capture a video stream for a robotics project (I've seen other projects that suggest at least image capturing from the camera is possible by direct output, as opposed to using I2C).
I would like to keep the other PRU free to run a half duplex UART out to some Robotis Dynamixel servos. I originally tried to read the camera from a program running on the main core. I had TIMER7 putting out a 12Mhz clock to the camera, and the VSYNC, HREF, PCLK, and the 8 bit parallel video lines coming into one of the GPIO banks. The VSYNC line appeared to be signaling 15 times a second, which was expected. An oscilloscope reading suggested the other lines were signaling at about the right intervals. It just seemed like something in the process of reading the GPIO pins was not keeping up. I thought since the main core runs at 1Ghz and this is bare metal I would have plenty of cycles between PCLK signals to read and handle the data, but I was only getting the expected data every so often, with a lot of garbage coming in between. So I decided to go the PRU route hoping the more direct GPIO access and determinism would make for a reliable process. Since the camera is running at 15 frames a second at 640 * 480 (YUV, so 2 bytes per pixel), I would have to pump 9MB a second to where this is getting stored, with at least 614KB to store one frame (and I would kind of like to back buffer it for computer vision processing, so double that). If this is just crazy, please let me know. BTW, I haven't actually written the code to read the PRU GPIO pins yet. Do I have to set the pinmux up in the regular pad control registers, or is their muxing controlled completely by the PRU registers. Thanks again for all of your help! On Thursday, June 11, 2015 at 3:19:38 AM UTC-4, Karl Karpfen wrote: > 2015-06-10 18:24 GMT+02:00 William Hermans <[email protected] <javascript:> > >: > >> >> 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. >> > > > I don't know if this is a good idea. I think this would lock both PRUs > when accessing shared RAM because only one can access it at the same time. > As far as I remember TRM, a PRU writing to DRAM would halt the main core, > not vice-versa. When this is correct the additional write/read operation to > shared RAM not only wastes a full PRU core but also adds some additional > delays without winning something. > > On the other hand: how much data do you really retrieve from your camera? > And how long would data transfer to DDR really take comparing to the > remaining time between two pictures? > > -- 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.
