SparkFun Forums

[KreAture]

I'm in Oslo westhoff.

I looked at using synch comms, but I'd have to get the cam to deliver something practical vs 20 MHz. Also, if running synched you'd need a lot of cycles pr clock anyway to check HBLK and VBLK status as you capture.
With the cam on PLL running over 8 MHz output that will be hard.

I thought I had posted a url to my footprint, but apparantly I didn't?
Maby just in some PM then.

Anyway here it is:
http://kreature.org/ee/avr/cmos_cam/TCM8240MD.lbr
It has been tested.

[westhoff]

KreAture,
I visited Oslo two years ago, I was just curious. I have a friend that lives south of Oslo near Tønsberg.

What is your current progress with this chip? Have you found a better camera chip?

I saw the footprint, I was thinking about seeing the code you used to initialize the chip. I am only interested in the jpeg mode to decrease the memory/bytes needed to send a picture.

Reading the data sheet it looks like you could run the AVR at 20MHz, the Cam at 10MHz. The idea I had was that being synchronous (not in jpeg mode) you could ignore the HBLK as it is always the same number of clocks between them. Make your code loop using NOP's to be the exact time between HBLK pulses. You would still have to check VBLK, but you should be able to do that OK. It is just an idea that was in my head. I did something similar before on another chip but it was not a camera.
Tom

[reklipz]

I just remembered, the PIC18F4550 has a streaming parallel port so that large chunks of data can be sent via USB without the need for the uC to process it all. The only problem would then be making sure the uC can get through the packets from the host fast enough, as the host has to initiate all communications, and there is a maximum packet size. It may still require some sort of external storage from what I gather about other peoples' posts.

[KreAture]

westhoff
The cam really doesn't behave as nicely as you think.
In jpeg mode it sends data in tiny chunks. You have no idea when it will start sending data as it does so on it's own accord. You also have no idea how many clock tics there will be before some more data is ready and it may only send you a couple bytes.
There is a 4-byte mode on it to force it to send 4 byte blocks, but It doesn't help much as you never know when the blocks arrive unless you stare at the HBLK signal.

Remember, you need a lot of cycles to do a simple loop...
- get byte from port, 1 instruction
- save to memory and post increment pointer, 1 instruction
- check hblk 1 or 2 instructions
- loop if not done, 2 instructions or more
That's a minimum of 5, most likely 6 or even 7.
The slowest I can get my cam to output with a 6 MHz input clock is around 7.5 MHz. That means you'd need to run at 50+ MHz to keep up.
A bit more if you want to run asynch with the dclk.

[westhoff]

Looks like some kind hardware fifo would be best then.
Have you decided to use another camera chip?

westhoff
The cam really doesn't behave as nicely as you think.
In jpeg mode it sends data in tiny chunks. You have no idea when it will start sending data as it does so on it's own accord. You also have no idea how many clock tics there will be before some more data is ready and it may only send you a couple bytes.
There is a 4-byte mode on it to force it to send 4 byte blocks, but It doesn't help much as you never know when the blocks arrive unless you stare at the HBLK signal.

Remember, you need a lot of cycles to do a simple loop...
- get byte from port, 1 instruction
- save to memory and post increment pointer, 1 instruction
- check hblk 1 or 2 instructions
- loop if not done, 2 instructions or more
That's a minimum of 5, most likely 6 or even 7.
The slowest I can get my cam to output with a 6 MHz input clock is around 7.5 MHz. That means you'd need to run at 50+ MHz to keep up.
A bit more if you want to run asynch with the dclk.

[KreAture]

No way!
I have 5 of these! I'll make em usefull even if it kills me!

Right now I am writing a font for my 84x48 LCD display so I can use it in a logger I am making. Once that's done I'll get back to the cam.

[westhoff]

KreAture,
I was thinking that this camera might be a good application for the new AVR XMega processors. They have a separate peripheral bus that works independent of the processor including DMA. Also run at 32MHz which should help. Just a thought, haven't looked that closely yet.
Tom

[KreAture]

Yes westhoff
I've been pondering that myself.
I am still waiting for samples at work though...

[westhoff]

KreAture,
Do you have any idea of the file sizes for jpeg mode? (How much ram needed to buffer a photo)

Did you want to send streaming video, or snapshots?
Tom

Yes westhoff
I've been pondering that myself.
I am still waiting for samples at work though...

[KreAture]

Both stills and low fps video.
No streaming really. Just storage to flash.

As for filesize, it is really up to us as it is possible to set the quantizer/compression.

[Twingy]

I got the TCM8230MD working, here is an image I captured from it...

[KreAture]

NICE!

That's in RGB or YUV mode right ?

What was the names of the registers you had to set to get the contrast stuff ok ?

[Twingy]

This is RGB565 @ 128x96 (12288 bytes of RAM). Didn't touch the contrast registers... I'm thinking I should be able to process 5-8 fps once I clean up my FIQ ASM routine. I'm still dorking around with resolutions and colors and stuff, not quite ready to reveal all my cards just yet.

[Twingy]

Here is an image to demonstrate I've got color working now... As of this posting I can capture and process 4.5 (128x96) frames per second on the AT91SAM7S64... I could do 4.5 (160x120) frames if I had the AT91SAM7S256, but for my application it's not necessary just yet. My assembly routine is 11 instructions, but I'm focused on trimming that down so I can perhaps achieve 5 or even 6 frames per second. Once my ARM9 9261 kit arrives I should have no problem doing 30 fps at 160x120.

[KreAture]

Nice!
The TCM8230MD seem a bit simpler than the TCM8240MD.
The cropping is all wrong on the TCM8240MD and that has been wasting a lot of my time. Also, it appears to shoot only green color in RGB mode.