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.
