USB CMOS Cameras .... Any good?

In article <>, cerbero85
@n_o_s_p_a_m.gmail.com says...
> 
> Thanks for the replies
> 
> >In article <>, cerbero85
> >@n_o_s_p_a_m.gmail.com says...
> >
> >Sounds like a student project.
> 
> Yes.. and I have available a low budget.

So think about the data flows.
 
> >Do you want a single frame, every second or third or... frame or all 
> >frames?
> 
> Full frames (400x400 pixel to 30FPS)

So single frame to 30fps, where a frame is 400 x 400 ( pixels)

> >Step one READ every part of the camera datasheet
> >
> >Step two work out the size in bytes/words the size of a whole image 
> >frame. How fast the data is coming as it CANNOT be paused.
> 
> I decided of use only 8bits. The camera frame rate is 30FPS.

So you are doing monochrome at 8bits/pixel, if you are doing colour
at 8bits multiplex you are doing at least 16bits/pixel. 

This means 320,000 byte per frame.

At 30fps that is 9,600,000 bytes per second.

In bits that is 76,800,000 bits per second.

So without compression, which often adds further delays without
dedicated chips, you will need a minimum of USB2 High Speed (480Mbps)
as Full Speed (12Mbps).

As long as nothing else is at the same time using the USB with
high data throughput (e.g. saving video to disk).

This also means you need to know more about the datastream and
how it is encoded (see the camera datasheet).

> 
> The A/D convert works at 8MHz.

Does not seem fast enough, also consider a TDA 8but 40MHz
and very cheap.
 
> So the size of one frame is:  400 x 400 x 1byte = 160KB 

In Monochrome, it is definitely 160,000 PIXELs, number of 
bytes per pixel is determined by the formating of the sensor.
 
> >Step three work out a method to grab the WHOLE frame into some local
> >storage in ONE go. 
> 
> I found this: AL422B FIFO  384K x 8bit

In 8bit mutliplex BT656 format the 320,000 will fit one frame and a 
part frame.

> >Step four then start working out what you are going to do with data
> >if going by USB you cannot guarantee the host will always come back
> >for your data stream.
> 
> This I didn't understand?

USB depends on polling from the host so if not polled quick enough
and latency periods, will cause data overruns. I.E. you have a full
FIFO and cnnot take any more data in, but the camera will still
produce data.
 
> >Step five look up USB specs and UVC class devices unless you also
> >want to write a windows/linux driver.
> >
> >Once you know what you are trying to do THEN sort out the parts you
> >require...
> >
> >The parts you have chosen are woefully inadequate
> >
> >SN74ALVC is 512 x 18bit FIFO, just about one line of data
> >
> >NXP LPCFBD64 is the SMALLEST device in the range having 8k SRAM 
and
> >2K endpoint RAM and NO DMA.
> >
> 
> I found this chip:
> 
> FIFO Averlogic AL422B is 384K x 8bits (is possible store two frames)

It is better device, but you still have not done enough data and timing 
analysis, on what you require for the data throughput and timings.

> and
> 
> Microcontroller Stellaris LM3S 50MHz  64kB SRAM and 128KB ROM and 
> DMA
> 
> You know a microcontroller with USB that support UVC?

Read the USB spec on the subject as this is mainly software on the 
micro, with enough endpoints and hardware ability to transfer the
data between a parallel port and memory (internal or external) and 
then to USB buffers.

You still need to work out data timings for the system. To see if
you can move upto 10MB per second in and out all paths at the same
time.

Oh and have enough spare time to run some software to control this.

-- 
Paul Carpenter          | 
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate