SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By rgbphil
#48419
We'll get there eventually.
I contacted FTDI about the feasibility of a streaming input for their Vinculum chips....they don't have any plans for one though.
However they did mention that the Vinculum chip has a parallel input (as well as RS232, I2C etc)....so maybe that will be suitable. The micro could send the setup/command codes then hand over to a streaming clocking circuit to dump the image file, then clean up afterwards.
Will have to look closely at the Vinculum datasheet.....not the easiest of things.
By aaronharper1984
#48633
I apologise in advance if I get laughed out of here, but I have never befor e used an 8-bit parallel interface. I have no idea how to even start conecting it to my micro (LPC2138). I can connect my micro to my uSD card no problem, and feel confident enough that if I can find a camera that I can use, I'm a few short steps away from my own home made camera. Could any kind soul point me to a link that will give me a breakdown of this interface please?
By KreAture
#48673
The interface for the data stream on this cam is simply 8 paralell wires each containing a bit simultaneously. There are seperate signals to tell you when the bits are valid.
Look at the datasheet for full details.
By henryhallam
#48744
It will not be easy to interface this to an LPC2138. Need something faster or with a DMA-enabled parallel interface. I'm working on doing it with a Blackfin, will keep you guys updated.
By henryhallam
#48746
KreAture, would you be interested in sharing your Eagle files? If so, I'll get a dozen professional boards made up with solder mask and mail them out for $4 each shipped.
By aaronharper1984
#48749
I guess that shows how little I know about this kind of project, I've always found my LPC to have plenty of headroom. What uC's is everyone using?
By henryhallam
#48759
The trouble is that the camera module is acting as a master - it is sending data out at a high rate, around 10 MByte/s depending on clocking, and it controls the clock. So really any microcontroller without a dedicated parallel interface will have trouble keeping up, because if your controller is doing say 40 MIPS you only have 4 instructions to receive each byte, save it somewhere, and keep the clock in sync. And few microcontrollers have enough memory to hold a whole frame at a time, even with the JPEG.

The easiest solution to interface to a regular micro is to use a FIFO buffer IC big enough to hold a whole frame, so the micro can clock the frame out as slow as it likes.
By KreAture
#48765
The sad part is the price of such a FIFO...

I am not sure if the ARM7 dma can help or not.
It doesn't look like it can be clocked from an external pin directly but might need interrupt. That would make it too slow.
By Assen
#48785
May be two avr microcontrollers working with time sharing and writing in two separate sd cards can help. That way we will have half of the time to set up writing a new portion in the sd and during this time the second micro will write the missing part of the image. The synch can be done by counting the clocks from the camera from the timer. Only an idea.
By pellepl
#48793
Another idea is to get a (big) 8-bit sdram and a counter. Connect clock to counter which acts as address, the data bus to .. duh .. the data bus, and another clock-trace to read strobe of the memory.
By henryhallam
#48794
I don't think the ARM7 dma is useful for this.
I remember finding a FIFO that was suitable and in the $15 price range, I'll try to find it again.
By Twingy
#48799
I'm presently using an AT91SAM7S64 to access the TCM8230MD which poses the same problem as the one you are facing with the TCM8240MD. Keep in mind that you have some breathing room between each horizontal line that comes in. I'm working at 128x96, so a 256 element buffer should suffice... I just finished writing some C/ASM hooks into my dev environment for the FIQ. At best I'm seeing about 100nS latency to access 0x1C on the ARM7 FIQ handler and perform a single instruction. I'm using PWM hardware to drive the clock on the camera. I'm about to see how slow I can clock the camera. If I can get the clock to be stable at 3-4mhz (well outside the specification) then I think the FIQ plus my ASM routine will work. This would give me about 250ns between DCLK's on the camera.... I made my protoboard on the LPKF-S62 protomill I have here.
Last edited by Twingy on Thu May 22, 2008 1:02 pm, edited 1 time in total.
By KreAture
#48802
Assen
At 20 mips you would only have 3 instructions pr camera clock when clocking cam at spec speed. This is too slow to even check sync.

Twingy
Great that someone else has gotten this far :)
Are you getting proper data?
I am having trouble getting the cam to deliver rgb images correctly. Mosly I get either black or half a pic with only green.

In 128x96 I use a row-buffer of 256 as each pixel pr row is 2 bytes in RGB mode.

As for clocking, enabeling pll and fiddling a bit with the upper bits in that byte-register can give something like 5.7 mhz if you underclock the system. The odd thing is, it looks like when you turn on the pll, the cam outputs a clock opn extclk ??? I will have to verify this by turning off my extclk signal after enabeling the pll...
By Twingy
#48813
I have experimentally determined that on the TCM8320MD I *must* feed EXTCLK of the camera *atleast* a 6MHz signal (datasheet says 11.9MHz minimum) in order to send the TWI (I2C) cmds to activate the camera and begin producing a DCLK signal. I also determined that I can then change the DUTY and PERIOD of the PWM from 6MHz to something much lower and maintain the DCLK signal. WARNING!!! just because the DCLK signal is OK and the TWI (I2C) still works does not mean the data coming off the camera is OK. I do not know if the Camera is using DRAM that requires a minimum clock speed or if the minimum (11.9MHz) clock speed was defined as the minimum speed you want the camera to run to minimize *BLUR*. As of this moment in time I am writing straight ASM in the 0x1C address of the ARM's FIQ to read the PIOA ODSR for the upper 8-bits on the GPIO, shove into a 256 pixel component buffer (128x96 resolution... 2*128 = 256...) and increment a counter... ALL WITHIN 300-400 ns. Note to you other masochists... There are ARM7/ARM9 processors (Liminaire) that have Camera DMA circuitry on them if you want to take the *easy* way out *grin*. I am running my AT91SAM7S64 at a frequency of 86,016,000 Hz.
By KreAture
#48818
Nice. I wish I could get the proper docs for this AT91 so I can configure the internal PLL. Right now it runns at 18 MHz.

If only I can get the speed up and see if I can get the PIO or DMA controller to do my bidding :)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 31