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
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.
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
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>>.
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…
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 ? :?:
sounds like a job for SRAM and a DMA channel. Of course an FPGA would work as well.
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.
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.
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
I should mention I work with HW development and have already used my contacts to try and get a better datasht. I ended up getting the same datasht 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.
Well… I did it!
I got something out of the cam, not relating to utter garbage…
http://kreature.org/ee/avr/cmos_cam/woh … 128x96.png
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:
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…
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.
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!
Well, I’ve got a couple of these and it’s little brother, and I’m excited to start using them.
I’ve hand soldered wires (that terminate in a .1" male heading) to all 24 leads of the larger one, but I’m afraid to start coding. I don’t expect to capture an image, but I’m hoping that at least my solder job wasn’t for not and that I can get some sort of response from the camera.
As for a breakout board, I’m interested in obtaining one as well. I’m afraid that even if I did solder the wires correctly, they may be susceptible to noise and the heat from the soldering iron may have ruined the camera sensor(I doubt it, but I hear they are really sensitive…).
ghavenga, the large amounts of data come out via 8 bit parallel, not I2C, so the SPI converter may not be necessary…
KreAture, awesome job on the image capture! was that done with jpeg, YUV, or RGB output?
-Nate
The image capture was in RGB mode, and only the blue data was sent to host. (green bits masked to 0)
Unfortunately I do not know what register modification made the cam behave at all, so I can’t reproduce it yet. Atleast my code now allows me to capture data up to 320x240 while sending to PC and my rs232 is running at 900kbaud now.
If only I can get the cam in full auto mode for brightess, contrast, exposure and color balance it would be easier to get the x/y setting correct.
The breakout board is running ok, but I think I will add a small change with some sort of level conversion. 2.8v of camera is not practical for avr’s especially ones you want to run at very high speeds maby even overclocked. I’ll rack my brain and see what I can come up with.
New progress…
CBMODE flag means Color Bar Mode 
(duh?)
At 160x120 mode it then spits out this:
http://kreature.org/ee/avr/cmos_cam/cbmode_0-7.png
The image has been auto-level converted as it was alost entirely black.
RGB mode again, only blue data.
I had to expand my code to split the 565 RGB data to 888 so I could get this image. It was worth it to finally see colors
http://kreature.org/ee/avr/cmos_cam/cbmode_rgb_3-7.png
I think it’s inverted though as I send BGR not RGB :lol:
Atleast it’s possible to keep up with the chip in RGB mode if you cheat a bit on the clock input
I’ve been following this thread and thought some people might like to know Xilinx is running a special on a development kit for their Microblaze processor. Supposedly for $395 it has a full license for their EDK, a USB download cable + some hardware to play with. The kit is:
DO-SD1800A-EDK-DK-UNI-G-J-PROMO
http://www.xilinx.com/products/devkits/ … -UNI-G.htm
Regards,
JD