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.
