SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By monzasteeve
#46116
Finally a nice megapixel camera with JPEG!

Question for Sparkfun: before we start messing with it, is a connector planned? Also code example? Although it seems trivial to control it, we might need to be careful in some regard....?

Greetings,

Ste
By rbreese
#46463
I got a couple of these in, were confused at first by the pads on the bottom and the pads on the sides. But after looking at it under a microscope, I see the pads on the bottom are connected to the side pads.
By monzasteeve
#46483
So you mean you can just solder them on a pcb? I know, not neat, but would that work...?
Did you manage already to snap a pic?

Ste
By rbreese
#46519
These things are so small, you have to solder them - I do not see anyway to prototype with them. It is going to take me a while to do anything with them because first I have to make a PCB breakout board so that I experiment with them.

I know that I saw the picture of one sitting on a quarter, but their tiny size did not really hit home until I saw one in reality.

<<I am having a hard time posting on this forum because of forbidden words, of which I have no idea what they are>>.
By KreAture
#47041
I got a bunch of theese too.

So far I got a breakout board done and have it powered with 2.8 and 1.6v.
I can talk to it with i2c and it responds correctly.

If only the datash**t (yes, apparantly we can't say that word here!) had explained what most of the registers actually do I'd be very happy. As-is I can:
- put it to sleep
- enable/disable DOUT
- Select RGB mode
- Enable JPEG
- Invert horizontally/vertically
and possibly select image size...

What i can't do is decide when it will take a picture or throttle the dataflow.
This thing appears to be pumping data out the 8 bit wide bus at 1/2 the input clock. This clock has to be atleast 6 MHz and maximum 20 MHz for a blistering (in out context atleast) datarate of 3-10 mbyte/s !

I want the second half of the datash**t...
By KreAture
#47107
Well, I've been having fun...

I can control the image size and have counted bytes coming from the cam in RGB (565 mode) so I know the resolutions from diff settings now.
Unfortunately I don't have enough memory to grab a complete image and send it on to PC or memorycard. Even the smallest image (128x96 = 12288 pixels) is 24576 bytes. My AVR's have 2 to 8k memory at most.
Also, the datarates are too high to send it on "on the fly".

I've been poking through the entire registry of the cam to see if I could maby slow the data-clock when using the PLL. Looks like one can't. Basically, enabling the PLL gives around 7.3 to 8 MHz data-clock at lowest setting. It spreads the jpeg data out over long intervals, mostly being blanked by HBLK but when there are actual data they do come out at 8 MHz... My avr, even at max speed of 20 MHz won't have many cycles pr byte. Not enough to synch to DCLK, read data, save to somwehere, repeat.

Anyone having more luck ? :?:
By Philba
#47126
sounds like a job for SRAM and a DMA channel. Of course an FPGA would work as well.
By KreAture
#47130
Well, I initially bought the cams for the I2C. I didn't even see the fact that they couldn't read out the data via I2C.
I had also just perused the datas**t so I didn't realize how poorly the registers and functions were documented either.

My hope was to use this directly with a MCU, but it is looking very doubtfull. Too bad, this means more electronics and more bulky pcb.
By KreAture
#47198
If anyone has any information on how to reduce the data-clock during jpeg transfer, please let me know...
I can get it down to 7 MHz, and running avr at 21 MHz gives 3 cycles/tick.
This isn't enough to do a nice no-addons interfacing so I need more. I just hope I don't have to put in a FPSLIC or Xmega to get it to work.
By monzasteeve
#47200
This is indeed one of the key points i wanted to clear out before starting developing with this new module! Glad that someone tried, but I feel your troubles at the moment man!

This could be a show stopper, in my view if this problem is not overcome, the module loses a lot of interest.

Any chance the good Sparkfun people could get more info directly from the producer?

Ste
By KreAture
#47203
I should mention I work with HW development and have already used my contacts to try and get a better datash**t. I ended up getting the same datash**t from Toshiba Germany as already posted on sparkfun. The fun part was the datash**t from Toshiba Germany was tagged "alldatasheet.com" in the document title-property.

Maby they have lost the documentation?
I have looked at similar products but not found any with same register layout. What I don't get is why I can't find any dataclock divider setting for jpeg mode. Almost all other cam chips and modules seem to have such a thing.
By KreAture
#47231
Well... I did it!
I got something out of the cam, not relating to utter garbage...

Image
This is blue channel only, 5 bit data sent to pc from an Atmel AVR while simultaneously reading from cam and buffering overshooting data using cam in RGB mode.
I have no idea how to get it to send the right area of the image yet, nor how to enable AGC and such nice automatic stuff, but it's a start.

AVR was running 16 MHz and rs232 comms were running at 403200 baud.
So far the setup can only handle 128x96 images but it's a start... :twisted:
By KreAture
#47325
Hi guys... I had a notion.
Maby the cam adheres to some standard?
That mobile imaging standard is a prime candidate but does it specify commands/registers ?

Edit: SMIA doesn't look like it defines any registers by address, only by name. Ofcource the names do not match the modules datash**t...
By ghavenga
#47397
Gee, I want to post, but I can't because of some forbidden words - kinda funny because all i'm posting is some info and links.

I'll try again making the links "non-active" - maybe that's what the thing's complaining about.

I don't mind putting stuff on that keeps the spammers out, but some clue as to why I can't post a particular message would be very nice.
By ghavenga
#47399
Look familiar?

http://www.ovt.com/pdfs/pb_9650.pdf

Yes, it appears there's a standard - I don't know about the image data format, however.

I've got a Altera Cyclone II dev kit - something tells me I'm going to be using that for prototyping...

KreAture - any chance you'll be offering copies of your breakout board (for a price, of course!)....

I found these links too. (go figure datash**t is a bad word. replace the '*' s with 'e's in the following links and you're good to go)

http://translate.google.com/translate?h ... l%26sa%3DN
http://www4.cs.umanitoba.ca/~jacky/Robo ... v-sccb.pdf
http://130.237.218.17/datash**ts/camera ... omSpec.pdf

I think I'm going to try to put together a little CPLD that will serialize the image data so I can read it via SPI.

I found this nifty little chip too for converting SPI to I2C. That way, I can have a SPI interface to a number of cameras. The idea is that I can perhaps use SPI to keep up with the image data...

http://www.nxp.com/#/pip/pip=[pip=SC18IS600_601_4]|pp=[v=d,t=pip,i=SC18IS600_601_4,fi=51853,ps=0][0]

This is the board I'm thinking of using as a camera controller / interface...

http://www.atmel.com/dyn/products/tools ... ol_id=4102
http://www.avrfreaks.net/wiki/index.php ... tation:NGW

This should be fun!
  • 1
  • 2
  • 3
  • 4
  • 5
  • 31