SparkFun Forums

[Twingy]

Keep in mind the fastest I can drive the camera right now is 3.5328 MHz to allow for approx 500ns to handle the FIQ interrupt, buffer the byte, and increment a counter (among other things).

[Twingy]

I completely rewrote the assembly handler, removed the interrupt on dclk, and now I'm getting 10.4 frames per second at 128x96. I can bump it up 17 frames per second if I only focus on the red or blue channels. Right now I am generating a 7-bit grayscale image from the RGB565 image data. I think I won't be doing much more development work since I can basically get the camera to do what I want now...

[Tivon]

Just bought it and looking forward to joining the hackfest!

[BusError]

Anyone tried to drive these with a CPLD + SRAM, an serialize the output at a lower frequency to the MCU ?

[Twingy]

I don't think so, but that would certainly be valuable for those that wish to use the camera on an 8-bit PIC or AVR.

[westhoff]

This looks interesting:
http://www.qpixeltech.com/docs/QL305%20 ... 0Brief.pdf

[MIUN]

Hello,

I also want to work with the camera TCM8240MD.

Is there a socket provided for that camera? And how do the pins look like? Are there actually pins lead out to the sides of the package or are the pins on the lower side of the package? Does anybody have a more detailed documentation about the dimensions?
It would be also nice to see a detailed picture of the pins of the camera.

Thank you very much!

[westhoff]

Here is link to camera, datasheet link has all the info.

http://www.sparkfun.com/commerce/produc ... ts_id=8668

[monzasteeve]

The thread has been silent for a while... KreAture, Twingy, any progress you might want to share..?

Ste

[KreAture]

I for one have been looking into the avr32 in case it could be used.

[ghavenga]

I've got the ATNGW100 board and am trying to do the same thing.

I bought three of these camera modules and am trying to figure out the best way to use them (I want to be able to run all three of them one at a time).

I was almost thinking of a EPLD that allow me to switch between them, for both I2C (unless someone has figured out how to give them separate addresses) and also to provide the addressing for a SRAM large enough to hold an entire frame.

I'm planning on running in JPG mode, so that would make the input side to the RAM easier.

I was thinking it that I could use SPI between the AVR32 and the camera boards - the clock can go pretty fast, so I should be able to read out in a reasonable amount of time - and that's another function the EPLD would have to do.

Unfortunately, I'm more of a software (firmware, drivers) head than a hardware guy, (although reading data sheets and schematics are second nature) so I'm leaning on my co-workers to help me out there, but it's slow goin'.

I was also thinking of having logic to decode the JPG blocks in order to be able to figure out when a frame was complete, but that moves the design from a EPLD to an FPGA (although, Cyclone III's can be had for $13 qty 1)...

I _might_ have access to our boardmaker (PCB mill), but I dunno - seems like every time someone uses it, they break it and it's expensive to fix.

I'd be very interested in teaming with someone (everyone, really) to work this out.

[The_Spide]

I preface this message with a note with I'm new to the <strike>Dark</strike> hardware side of things.

Would this be a suitable FIFO, AverLogic's AL422B 3-M Frame Buffer

http://www.datash**tcatalog.com/datash**ts_pdf/A/L/4/2/AL422.shtml (replace ** with ee)

Pros:

• 8 bit words - matches the cameras 8 x DOUTs.
• Two clocks, enables one for write and one for read.

Cons:

• At $8.90 almost as much as the camera itself.
• Not big enough? The buffer is only 393,216 Words (See my understanding of the amount of data produced)

Assuming I'm reading the diagrams correctly for each
rising DCLK while VBLK and HBLK are high there will be an 8 bit word out output...

• Full Mega output without JPEG = 1024 * 2560 = 2,621,440 words
• VGA ( x1: no zooming) = 959 * 1280 = 1,227,520 words
• VGA (at maximum magnification x2) = 480 * 1280 = 614,400
• CIF ( x1: no zooming) = 957 * 704 = 673,728
• CIF (at maximum magnification) = 288 * 704 = 202,752 (This would fit)
• QVGA ( x1: no digital zooming) = 956 * 640 = 611,840
• QVGA ( at maximum magnification. X4) = 240 * 640 = 153,600 (This would fit)
• QCIF ( x1: no digital zooming) = 954 * 352 = 335,808 (This would fit)
• QCIF ( at maximum magnification : x 6.67) = 144 * 352 = 50,688 (This would fit)
• QQVGA (x1: no digital zooming) = 952 * 320 = 304,640 (This would fit)
• QQVGA ( at maximum magnification: x 8 ) = 120 * 320 = 38,400 (This would fit)
• subQCIF ( x1: no digital zooming) = 950 * 256 = 243,200 (This would fit)
• subQCIF ( at maximum magnification: x 10) = 96 * 256 = 24,576 (This would fit)
• JPEG encoded full Mega = Unknown size (might fit)

As I see it implementation would be:
STROBE -> Both Read and Write Resets
HBLK && VBLK -> Write Enable
DCLK -> Write Clock.

Then you could clock the data out at your own leisure, (once you stop the camera taking any more pictures)

[KreAture]

Only way to stop camera seems to be to stop it's clock.
It doesn't seem to have any enable or single shot modes.

[pellepl]

Correct me if I'm wrong, but won't bit 7 of reg 04 on the TCM8240MD mute the databus of the cam (and bit 7 of reg 03 on the TCM8230MD)?

[KreAture]

You are right pellepl, but on my tests it doesn't halt the camera, only prevents it from sending data. It still cycles through the loop and when I release the bit I usually end up getting my first data from the middle of a frame.