If you download the above project you'll find: README.md - general notes on the OV7670 example ov7670-cam/pru-ov7670-cape/kicad/ - KiCad schematic and PCB design ov7670-cam/pru-ov7670-cape/releases/ - PDF schematic and gerbers
I did not put buffers because straight connection works fine for me. But for any semi-serous use you should put buffers between the OV7670 (2.7V) and Beaglebone (3.3V). That said, the connection is straightforward: lcd_data0.pr1_pru1_pru_r30_0 <-> do not connect lcd_data1.pr1_pru1_pru_r30_1 <-> XCLK lcd_data2.pr1_pru1_pru_r31_2 <-> D0 lcd_data2.pr1_pru1_pru_r31_3 <-> D1 lcd_data3.pr1_pru1_pru_r31_4 <-> D2 lcd_data4.pr1_pru1_pru_r31_5 <-> D3 lcd_data5.pr1_pru1_pru_r31_6 <-> D4 lcd_data6.pr1_pru1_pru_r31_7 <-> D5 lcd_vsync.pr1_pru1_pru_r31_8 <-> D6 lcd_hsync.pr1_pru1_pru_r31_9 <-> D7 lcd_pclk.pr1_pru1_pru_r31_10 <-> HREF lcd_ac_bias_en.pr1_pru1_pru_r31_11 <-> VSYNC uart1_rxd.pr1_pru1_pru_r31_16 <-> PCLK gpmc_advn_ale.gpio2_2 <-> CAM_RESET Regards, Dimitar сряда, 29 април 2015 г., 19:36:33 UTC+3, Bill M написа: > > Greetings Dimitar, > > I can't thank you enough for the direction (I was afraid no one would want > to slog through all that). I'm also interested in the hardware part of it. > Are there any schematics for interfacing the camera to the board (will I > need caps, resistors, voltage translations)? The few I have found online > aren't completely clear. I may still go the OS route if the learning curve > isn't too steep. I would still love to learn how to handle the PRU stuff in > bare metal, though, so I need to get busier with the Starterware. Again, > thanks for the help! > > On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, [email protected] wrote: > >> Hi,ov7670-cam/pru-ov7670-cape/releases/ >> >> The servo control sounds like a job for the PRU. PRU I/O is also suitable >> for interfacing OV7670. Here is a rough but working example for Beaglebone >> White: >> https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru . >> Note that the example loader uses Linux and uio_pruss driver instead of >> Starterware. >> >> Regards, >> Dimitar >> >> >> понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа: >>> >>> Greetings all, >>> >>> >>> I'll apologize for the big lead up, I just want everyone to know where >>> I'm coming from. I also apologize if I posted this to the wrong place or >>> reposted it. I'm new here and still finding my way around. >>> >>> >>> I am considering getting a BBB to use with my Robotis robot kit to >>> replace the CM-5 and CM-530 I've been using, and was hoping people here >>> could give me help/advice/guidance, or direct me to those who can, as I >>> have a million questions. I will start to list them here. Any help greatly >>> appreciated in advance. >>> >>> >>> I've already written firmware for both the CM-5 (which is Atmega128 >>> powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You >>> can see the source for these here: >>> http://sourceforge.net/projects/bioloidfirmware/ Obviously these are >>> bare metal firmware given that the extremely limited platform in both cases >>> couldn't practically support an OS. I would like to port my code to the >>> BBB. I want to stick with the bare metal approach, so I can go real time >>> without having to use a patch for the OS or Xenomai, and since I won't be >>> interested in a good part of the functionality of the board initially (also >>> I'm kind of a big Linux noob). I have already downloaded StarterWare and >>> started poking around. The big draw for me to BBB is the processor clock >>> speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge >>> memory (for the controllers I'm using now, we're measuring in Kb), and the >>> huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So >>> here are some of my initial questions: >>> >>> >>> •Is anything special required to use the full 512MB memory? In other >>> words, can I directly address all the available memory without having to go >>> through any special procedures? Could I theoretically declare a really big >>> structure (iike a MB or 2) or array and be able to handle it in code like I >>> always have? >>> •With the code I've written thus far, the servos are updated 128 times a >>> second. I have everything for doing that interrupt driven. I have a timer >>> fire an interrupt every 8ms that calculates the next servo target positions >>> and creates a packet to put in a buffer that feeds the shift register of >>> the serial bus. The serial bus is also interrupt driven. When the buffer is >>> loaded, an interrupt is enabled that fires whenever the shift register is >>> empty. Every time it fires, it loads the next byte from the buffer. If the >>> buffer is empty, it disables the interrupt. Receiving bytes is handled >>> similarly, firing an interrupt every time a byte is received to put it in a >>> buffer and empty the shift register. This allows the packets to be consumed >>> as quickly as the 1Mb serial bus can consume them. Could I do something >>> comparable on the BBB? >>> •My third, and heaviest question, is one of the main motivators for >>> considering the BBB (and moving away from the above mention controllers). I >>> would like to get into vision processing, so I would like to hook a camera >>> (maybe two) to the BBB. I don't want to use the camera cape (since I want >>> to be able to position the camera somewhere else on the robot). Could I use >>> something like the OV7670 hooked up to some GPIO pins? I was thinking >>> something along the lines of having one pin output a clock to the camera >>> (along with a pin for power and ground), and then have an input pin for the >>> HREF, VSYNC, and pixel clock, and have the pixel clock pin set to fire an >>> interrupt that would read the input pins that D0-D7 from the OV7670 are >>> connected to and push them into a big buffer in memory. I figure for a 640 >>> x 480 RGB565 image at 15 FPS, it would be about 9MB a second, and even if >>> every byte was taking 20 to 30 clock cycles to handle (I think each >>> interrupt could be handled much more quickly than this), it would only eat >>> up at most 200Mhz a second (I've seen some posts talking about using the >>> PRU for doing this). Does this sound totally off the wall? What would I >>> need to interface the pins from the camera to the BBB GPIO pins? >>> >>> I apologize for the long windedness of this. Like I said, I'm not really >>> sure even where to start, or how applicable what little experience with ARM >>> I already have is to this. Again, any help appreciated! >>> >> -- 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.
