Yes, i2cdetect should detect the camera. The C code in host/ov7670-i2c.c is tested and works.
But there are important prerequisites for the OV7670 I2C communication: - Ensure XCLK is running. - Pulse the RESET line and leave it set to VCC. - Either leave PWDN Not Connected (it has a built-in pull-down), or connect to GCC. Regards, Dimitar събота, 1 август 2015 г., 23:44:35 UTC+3, Bill M написа: > > 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.
