Hi Bill. I want to do this too. I checked your sourceforge rep and could not find your OV7670 interface. maybe we can collaborate. contact me thru www.baremetal.tech
later...................dd On Thursday, June 11, 2015 at 10:53:11 PM UTC+3, Bill M wrote: > > 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]>: >> >>> >>> 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bd7978ea-002b-4e1c-8d0d-a880cb96ae3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
