CMOS camera interfacing

Much depends on just how low-level you want to go with this. A popular option is the C329 module from Electronics123. The CMOS sensor is mounted with interface and support electronics, including a JPEG engine, so all you need to do is command the picture and then pull the resulting jpg image.

Another possibility, same folks, the Y201-TTL module, also JPEG:

It must be university project start time or late starters.

take

Go ask you lecturer/prof/mentor about data flows and work out what data you have and how quickly you are to have to deal with it.

Classic case of cart before the horse.

You know that the chip is a 5 x 6 CSP (Chip Scale Packaging), right?

Yes, if you run it at 200MHz and actively cool it. We got it to 96MHz and the chip is warm. You will need heat sink and fan beyond. Someone got it at 160MHz.

Why not? You have to clock one row at a time and jpeg compress it before the next row.

That would help.

You might be interested in reviewing the CMUcam architecture

I'm actually a mech. engineer a few years out of uni, So my actualy ee classes stopped before ever having to deal with data flows. I've always enjoyed electronics projects and hopefully with this one I'll learn how to deal with them.

CMUcam looks interesting. I'll take a look at that and try to get a better understanding of how it works.

I'm also really interested in this FIFO buffer, but am not exactly sure of the implementation. Would it go camera > fifo > jpeg encoder > sd card? Then a mcu would control it? What provides the clock signals?

I've also never worked with external sdram or dma. Does the mcu need to deal with the memory addressing?

--------------------------------------- Posted through

Thanks for posting this - nice to have the info. It strikes me that those parts listed on the wiki page - where the datasheets of the two camera chips are to be found - have gone missing from all distributors. Probably after the datasheets leaked? Amazing what an effort the party members put nowadays into staying in the dark. For a good and obvious reason, the really amazing (and troubling...) part is that they are centrally organized enough to manage it.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

The CMU sensor is around 300x300x8. They buffer 15 frames of 100,000 bytes each. OV9655 is 1000x800x10. You need 1M bytes per frame. The uC does jpeg encoding. OV9655 output the pixel clock at around 120M bits per second.

Yes.

t=

bette=

o=

So if I were to use the OC9655, AL422B, and PIC24HJ32GP302, I'd have an external oscillator to clock the input from the camera, then use the mcu clock for the output. I'd take the ouput from the FIFO into the mcu, encode to jpeg, and write to sd however fast it wanted to? Or would I take the output of the FIFO and write it to sdram in the mcu?

--------------------------------------- Posted through

I've worked with two different approaches to acquiring CMOS camera data:

The first is to use a FIFO buffer (AL422B, I think) between the camera and the MPU. The FIFO accepts the data at the ~24MBytes/second rate of the camera and makes it available for the camera at a rate the MPU can handle. ST has some dev kits that use this approach and include the camera.

The second method is to use a processor, such as the STM32F207, that has a built-in camera peripheral. The peripheral port accepts the camera data and puts it in system memory (Either the onboard 128K RAM or external SRAM) using DMA.

A third method, that I've not used, is to read the pixels with a parallel port, skipping pixels as required by the CPU clock speed. This means that it takes several frames to accumulate a single image. This method is used by many hobby robotics imaging systems. The CMU cam is a good starting point for this approach:

You might also consider one of the small linux modules like the Gumstix. They have hardware camera interfaces and lots of CPU speed and RAM. You'd better be comfortable with embedded Linux, though.

Which ever hardware you choose, you will eventually find that data on how to set up the camera is not easy to get. Omnivision requires NDAs and sometimes won't answer support emails even with an NDA. The publicly-available information is skimpy, confusing, and hard to find. It's probably easier to get support if your email ends in @apple.com! ;-)

Mark Borgerson

=A0The

This is not good enough, PIC24HJ32GP302 - 16 bits, 40 mips, 32K flash, 4K sram

I suggest PIC32MX575F512H - 32 bits, 120 mips, 512K flash, 64K sram.

You will need some of the sram for program space, since running from flash is slow.

You will need 32 bits for jpeg encoding.

de

Yes, if your FIFO buffer is big enough.

=A0 =A0 =A0

There is no sdram in the mcu.

I looked around a bit and found that the CMUCAM2 actually uses an AL422B FIFO chip. I must have confused that system with some other hobby robotics system that used the pixel-skipping method.

Mark Borgerson

I use a PIC24/26/32 (still upgrading) and a 3MP Android. Android compress it to jpeg for me, so I just have to move it to my own flash/ disk.

Why so small with 5MP camera?

Only if the sensor has a few hundred kilo byes of buffer. Otherwise, you will have problem with sharpness on motions.

I meant to ask what the OP's goal was.. if you have an Android device, what's the point of PIC anything anyway actually?

Sorry, the MT9V032 is different from the 5MP sensor. I was just saying that I have managed to make it work on the 5MP sensor which transfers the data continuously on its own timing. It would have been easier with the MT9V032 where you can throttle the data stream coming out of the sensor, to match your max storage rate as long as you can take one full line without data dropout. This is the case because that sensor has the global shutter feature, which is not common in CMOS cameras.

Steve

External I/Os and A2Ds.

It's a late reply, but one quite powerful and cheap solution is the SRV1 cam from

Cheers,

- Strubi