Hi Dimitar, Thanks for the suggestion. It looks like crosstalk was/is the issue, but I was thinking it was just the timing wires doing it to one another. It turns out it is the parallel pixel lines that are doing it to the timing wires. I moved them away from the timing lines, and the picture cleared up, even with 8 inch lines. Thanks again for all of your help!
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.
