Thanks a million Dimitar! You are, as always, awesome. That did the trick. The only problem I'm having now is with the color from the modules, it is practically non-existent. I have tweaked various registers, without much success (I've gotten a bit of orange for things that are bright red, but that is about it). I know my code is working correctly, because I also bought an OV7675 module and it is producing color perfectly. Did you run into any of this? I bought a 7670 from three different suppliers, and they all suffer the same washed-out color issue. Thanks again!
On Sunday, August 2, 2015 at 3:59:33 PM UTC-4, [email protected] wrote: > > 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.
