SparkFun Forums

[KreAture]

I used an fine-tipped dvm, and very maticulously checked each pad on the underside against all pads along the perimiter.
Then I mapped the functions to the pinns on the perimiter and saw that only ground pinns were being omitted on the bottom pads.

[KreAture]

I'm still having issues getting my cams to output correct image data.
The appnote sais to change a few values based on PICSIZ but I am not getting the results I was expecting.

BTW:
I've found a way to export the raw data from the cam in RGB mode as a BMP now, so it can be displayed on any image editor/viewer.

Anyone else having similar issues with garbled images?

Here's a sample of CB mode 4 in 640x480:
http://kreature.org/ee/avr/cmos_cam/640x480_cb4.bmp
It looks like it is supposed to I think.
The BMP file uses a BMP file header setting the format to Bitfield mode in RGB565 format so that the raw camera data can then be appended on the fly. No reprocessing.

Here's the image with same settings, CB mode turned off:
http://kreature.org/ee/avr/cmos_cam/640x480.bmp
Very annoying. I am sure there is just some settings to select the right output area of the sensor and maby some color/brightness stuff but following the appnote and datasheet doesn't appear to be enough.

[Twingy]

Sorry I haven't posted in a while I've been busy with my projects at work. Just to quickly summarize, I've been building little double sided PCB's using our LPKF S62 PCB mill for my little robots at work. They are fairly easy to solder/build, only 2 regulators and the camera, plus some through holes. I use a 20 pin JST connector to interface the camera board to my AT91SAM7 32-bit microprocessor. Using my custom assembly routine I can capture image data at 10.4 fps without the use of the DCLK interrupt signal. Keep in mind this is for the TCM8230MD, but I recently picked up some TCM8240MD cameras and I plan to use those on the next robot for the higher resolution. I am working on documenting everything for a technical note at work and I will try to post a link to the document once it is okayed for public release.

I am currently working with the AT91SAM9260 ARM9 now. The ARM9 has an ISI or hardware integrated I2C + 8-bit CMOS interface peripheral. So it's like having dedicated DMA hardware for these cameras. I'm ultimately going to be using the AT91SAM9G20 for my next project, but it's pin for pin compatible with the AT91SAM9260.

My recommendation to those wanting to interface this camera to a microprocessor is to get an ARM7 or ARM9 32-bit microprocessor. This should provide the path of least resistance. It may be another month or two before I post again, but feel free to use the forums instant message feature and I'll try to reply in a timely manner.

[KreAture]

I have been using an ATmega64 but it does not have the horsepower to do anything usefull except test my control-libraries and retrieve RGB data to verify.

I am just wondering what bits you are setting to get the cam to behave since mine does not. (ref my crappy images when not in color-bar test mode.)

[KreAture]

Oh, and I am almost done moving the libraries to avr32
That will give me lots of grunt and about the same HW when it comes to dma.

[RobR]

Hi.

Just registered here so that I can ask a quick question regarding this cam. It's not explicitly mentioned in the datash**t, but I assume in JPEG mode that DCLK is used to strobe the data. Can anyone confirm that this is correct?

Reading through the thread it looks like interesting times ahead. Seems to me that the only low-cost way to do this is to blat the data as quickly as possible into memory of some sort, and worry about decoding it all later.

edit>>

Another question: Has anyone tried the Full Mega output without JPEG mode? I know it's a lot more data, but at least the timing is consistent - unlike JPEG mode, apparently. I should add that I only ordered my modules the other day, so they haven't arrived yet .

[KreAture]

Yes, the cam created a DCLK based on your input clock, a divider and it's pll.

This means that max output clock without PLL is same as input clock.Minimum input is 6 MHz.

You can get the cam to divide down EXTCLK to DCLK by setting low rez outputs and reducing framespeed. 1/2, 1/4 and maby less.

When PLL is active, it tripples the speed. Lowest DCLK I have managed with PLL on is about 8.5 MHz.

PLL must be ON for JPEG mode.

DCLK runns all the time, and data is valid during the high pulse of DCLK and a minimum of 10µs before and after. I recommend using rising edge to trigger if using software to capture data so as to have as much time as possible before data is invalid. If using hardware, latching on falling flank may be better as then the setup-time has been longer.

HBLK is used to tell you when there is valid data. (Only when HBLK is high.)

VBLK is used to tell you that a frame is being transmitted. (Image.) It remains high during the entire image and can be used to synch to start of frame.

Now, if someone could tell me what register to change to get the camera to output a nice image and not just obscure art, I'd be very happy...

[RobR]

Cool. Thanks for the reply.

>>PLL must be ON for JPEG mode.

So does that imply that for Full Mega output without JPEG you can turn off PLL - in which case you could also reduce the frame rate.

All* you need to do then (according to the data sh**t) is to watch for the VBLK low to high transition, and count 2,928,768 clock pulses (which you're controlling) capturing bytes until the end of the image. 2.6mb of data later you should have a full-frame uncompressed image.






*Yes, I know it's not quite that simple

[KreAture]

The problem isn't synching. That part is very easy.
The problem is:
1. Where will you put 2.6 MB of data in a microcontroller that only has 8kbyte of memory?
2. How do you read, store, increment address, check for end of image or count bytes within the alotted time vs your cpu frequency... (My 8-bit avr's run at 16 MHz or so, and with cam outputting at 6, 3 or 1.5 mbyte/s I then have 2, 4 or 8 instructions pr cycle to do it all in.)

That's why I am going for a faster mcu with built in hardware for the DMA transfer of the data. Then I can focus on making the system for writing data to SD-cards for my camera project.

[KreAture]

Suddently realized... AVR32 does not have internal flash!
Wonder how I could have missed that for so long!

I'll have to choose something else later. I don't want external flash on my design as it will ruin the small layout. Oh well...

[RobR]

The problem isn't synching. That part is very easy.
The problem is:
1. Where will you put 2.6 MB of data in a microcontroller that only has 8kbyte of memory?
2. How do you read, store, increment address, check for end of image or count bytes within the alotted time vs your cpu frequency... (My 8-bit avr's run at 16 MHz or so, and with cam outputting at 6, 3 or 1.5 mbyte/s I then have 2, 4 or 8 instructions pr cycle to do it all in.)

That's why I am going for a faster mcu with built in hardware for the DMA transfer of the data. Then I can focus on making the system for writing data to SD-cards for my camera project.

Oh sure, I agree. It just seems like JPEG mode is a bit dead in the water for 2 reasons:

1. The sporadic nature of the data.
2. The fact that you have to use PLL which means a massively fast data rate.

Of course, with a Silabs running at 50MHz and 1.5 mbyte/s output we'd have 33 instructions per cycle - perhaps more achievable, no?

[KreAture]

I'll let you know when I've run it with the AVR32 at 150 MHz.
I'll utilize the dma too so I should be able to just trigger the storage for each DCLK. The AVR32 setup I have here has 32 MByte memory so I can easily buffer entire frames, even a short MJPEG clip.

[RobR]

I'll let you know when I've run it with the AVR32 at 150 MHz.
I'll utilize the dma too so I should be able to just trigger the storage for each DCLK. The AVR32 setup I have here has 32 MByte memory so I can easily buffer entire frames, even a short MJPEG clip.

Sounds good.

[buffercam]

I'm interested in capturing JPEG data from the camera at full resolution.
I'm now working with a PIC32 that can do 120MIPS at 80MHz (supposedly).
Since it only has 32KBytes of on-board memory, I'm hoping to buffer the image directly to flash memory.

This means that max output clock without PLL is same as input clock. Minimum input is 6 MHz.
...
When PLL is active, it triples the speed. Lowest DCLK I have managed with PLL on is about 8.5 MHz.
PLL must be ON for JPEG mode

So this 8.5MHz corresponds to a EXTCLK a little less than 3MHz. This is under the minimum spec of 6MHz that you referred to, but I guess it's best to use a 3MHz clock until I can verify that the microcontroller can handle data at a faster rate.

My plan is to set up interrupts based on two sources: HBLK and DCLK
On rising edge of HBLK, enable interrupts on the rising edge of DCLK.
On falling edge of HBLK, disable DCLK interrupts.

-David

[steven2008]

Hi pple ..

I am thinking of buying either TCM8230MD or TCM8240MD ..
seems like TCM8240MD is having more problem ...
which would you recommend ?

I intended to use a PIC uC together with the image sensor.
anyone have similar setup?
if possible, pse share the details, thanks.
(so that it will save my some grieves .. )