Oh, but I don't have the PWDN and RESET pins on the OV7670 connected. On Saturday, August 1, 2015 at 4:41:55 PM UTC-4, Bill M wrote:
> Greetings Dimitar, > > Sorry to bother you again. Were you able to get the I2C working with the > OV7670? I have it wired up as you do and am trying to read it in Debian > using i2cdetect. Should i2cdetect be able to read the SCCB bus? Any help > appreciated. > > Thanks, > Bill > > > On Thursday, July 9, 2015 at 4:27:41 PM UTC-4, [email protected] wrote: > >> Hi, >> >> For prototyping I used 4inch cables, dispersed as far apart from each >> other as possible. I had issues due to crosstalk between the wires. >> >> You could try using a ribbon cable where every second wire is connected >> to ground (akin to 80-wire 40-pin IDE cables). Try to keep all wire lengths >> roughly the same. >> >> Regards, >> Dimitar >> >> четвъртък, 9 юли 2015 г., 3:42:44 UTC+3, Bill M написа: >>> >>> Greetings Dimitar, >>> >>> I was wondering if you could offer me some more guidance? I managed to >>> get an OV7670 working with the PRU (I'm using PRU1), but I have noticed an >>> issue. If the VSYNC, HREF, PCLK, and XCLK wires are more than 4 inches >>> long, I get some incomplete or corrupted scan lines. Shorter than 4 inches, >>> the picture is perfect. Can you tell me how long are the wires you are >>> using? Any idea how I can overcome this limitation? Any help appreciated! >>> >>> On Thursday, April 30, 2015 at 5:06:54 PM UTC-4, [email protected] wrote: >>> >>>> 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.
