SparkFun Electronics Forum

I intended to use a PIC uC together with the image sensor.
anyone have similar setup?
if possible, pse share the details, thanks.

why on earth would you post this message on a thread with 150 other messages explaining why its not possible to store a 640x480x16-bit image in 30k of RAM to people who have asked that exact same question multiple times?

silic0re wrote:

I intended to use a PIC uC together with the image sensor.
anyone have similar setup?
if possible, pse share the details, thanks.

why on earth would you post this message on a thread with 150 other messages explaining why its not possible to store a 640x480x16-bit image in 30k of RAM to people who have asked that exact same question multiple times?

thanks for the reply ... I am curious ...
did I ever mention I going to store it in the PIC uC ?

i am just using it for processing ... maybe sending to USB directly ...
havent decide yet ... just sourcing for ideas ...

Thanks ...

I just wish the one person that has so far gotten a viable image from the TCM8240MD would tell me what register settings he used.

From what I can see it's black/white so apparantly color was either disabled or that was a single color-channel.
So far my cams, (yes I got a bunch of em), only send me horrible images but very nice testpatterns.

KreAture wrote:I just wish the one person that has so far gotten a viable image from the TCM8240MD would tell me what register settings he used.

Who was the person who got an image? Twingy got some small images with the TCM8230MD. Was there someone else?

Oh! So that was with the 30!
Nice, then I am still in the lead with this beautiful rendition:

Hi KreAture..
Can I get the part list of the breakout board you have developed for TCM8240MD?

Thank you so much

Hi KreAture..
Can I get the part list of the breakout board you have developed for TCM8240MD?

Thank you so much

Hi KreAture..
Can I get the part list of the breakout board you have developed for TCM8240MD?

Thank you so much

Ofcource ofcource ofcource

It is in this file, along with the eagle-project files for the board:
http://kreature.org/ee/avr/cmos_cam/TCM ... ut_1.1.rar

It's called .bom you can't miss it.

Sorry for the triple post It was giving errors so I couldn't know they are posted

Thanks btw

I've got this camera on a PCB with a 2.8V reg, a 1.5V reg, pullups on SDA, SCL and RESET and all the pins going to a 20 pin connector that leads to an ARM STM32 F103 VBT6, which is running at 72MHz.

While the ARM has a DMA controller I can't see how to use it to clock in data on an input port, it seems more designed to clocking in/out data from its peripherals e.g. the SPI or I²C interfaces. I may be wrong on this count and would love to hear it if so.

Before I start sending any data, though, I'm worried that the 3.3V of the ARM will upset the camera (which gives a max of 3V on its inputs).
I could add a series resistor to the ribbon cable, but have no idea what value to use to get a suitable voltage drop. Alternatively, if this will work without the series resistor (i.e. the camera can take 3.3V) that'd be great.

Also, I'm only familiar with programming these things in C - while I could learn assembler if needed it would be quicker to get this off the ground in C. With my ARM running at 72MHz and giving the camera a 6MHz clock, divided by two for 3MHz data I calculate 24 operations per data, roughly?
Is that enough that I could realistically write this in C or not?

While it would be nice to get an actual image output, my application just needs the centre of mass of colours matching a threshold - I'm not sure if this will be easier or harder but essentially I just need to see if incoming data is within a colour threshold and store its x,y values if so. The ARM only has 20KB of RAM and 128x96 at 565 needs some 24KB, so if I have to store an entire image before processing I'll need to cut some off or something.

Thanks for any help or advice!

Are you talking about putting 3.3V on the SDA and SCL lines for I2C?
That's what I'm doing and it seems to work fine. My datasheet says 3.3V max for those pins, so I guess I'm living on the edge.
(I'm using the TCM8240MD, I don't know the specs for the TCM8230MD.)

The datasheet doesn't specify a max for EXTCLK and RESET, so I figure 3.3V is okay there, too.

I wouldn't try putting 3.3V on PVDD and IOVDD since the datasheet does specify that it should be either 2.8V or 2.5V.
You also need a 1.6V power supply for DVDD.


Now that I look again... in the MAXIMUM rating sections, it says the maximum input voltage Vin (max)=VDD+.3, which equals 3.1V in my case since I'm supplying 2.8V to the chip. So I guess I'm exceeding that.

Maybe that's why Kreature put resistor pads in his breakout board?

Good luck.
-David

I've got two voltage regulators giving 1.50V and 2.79V for the right power supplies, so that should be fine, but I was concerned about the SDA and SCL lines. I guess I'll just have to try it and see.

Thanks for the information!

I got a clock pulse coming out of my ARM, and while I can't measure the frequency it is at least the right duty cycle so with any luck it should also be 6MHz. (I only have a DMM and no oscope yet).

The I²C lines are pulled to 2.8V and since it's all open-drain that should mean my ARM (3.3V) happily talks to it at 2.8V. I tried sending it the initialisation command and got 1.3V on the DCLK line which I guess means it turned on and there's a clock pulse there, but couldn't access the data lines to see if anything was being sent, and couldn't see if it was an actual clock pulse.

At any rate I then reprogrammed my microchip to read the DATA pins and turn on an LED when the MSB was 0, with the intention of shining a torch at the thing. Uploaded the new code and now it hangs on sending the START condition, no voltage on the DCLK line, the camera apparently isn't responding or my micro's just holding the line low for some unapparent reason.

Any ideas why it might be holding SDA low after sending START? Could I have fried the camera? (I wish it was socketed!)

Thanks!

Update: I made an LA using my parallel port (tfla) and hooked it up to SDA and SCL. I instantly noticed that the address was shifted by one! silly mistake, the but stm32 library asks for a 7bit address - turns out it wants a shifted 7bit address! (I wish the documentation would mention this kinda thing.... )



Anyway, I quickly fixed that and now have a lovely trace of the ARM sending the camera's address, 0x03 for the register, 0x00 for the new value. The camera should now be initialised!



Sadly this thing is only good for about 500k samples a second, nowhere near fast enough to watch the clock or data lines, but it's already got me started. Next step: trying to read the data!