CMOS camera to USB

Hi all. I'm making a project with a low-resolution camera and I want to
transmit the captured frames over an USB channel.

The camera is an Omnivision CMOS with 400x400pixel resolution(it uses a
bayer pattern) and 10/8 bit Raw output.

I saw the CMUcam project and if was possible i would make a similar
project.

I thought I'd use the following chips: Camera CMOS + FIFO buffer(Texas
Instruments SN74ALVC7804) + Microcontroller ARM7(NXP LPC2141FBD64)

I want to capture images and send them to the pc over USB...

In your opinion is possible to implement this project(with this chips)??
or have you any suggestions?

Best Regards,
Edoardo
  



	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dnZ2d@giganews.com>, cerbero85
@n_o_s_p_a_m.gmail.com says...
> 
> Hi all. I'm making a project with a low-resolution camera and I want to
> transmit the captured frames over an USB channel.

Sounds like a student project.

Do you want a single frame, every second or third or... frame or all 
frames?

The more frames you want the more hardware you will need in your
device and host, dedicated to image storage.
 
> The camera is an Omnivision CMOS with 400x400pixel resolution(it uses a
> bayer pattern) and 10/8 bit Raw output.
> 
> I saw the CMUcam project and if was possible i would make a similar
> project.
> 
> I thought I'd use the following chips: Camera CMOS + FIFO buffer(Texas
> Instruments SN74ALVC7804) + Microcontroller ARM7(NXP LPC2141FBD64)

I doubt it. Cameras are NOT like memory or disk drives, so the camera 
does not take a picture and hold it witing for you to read it.

The camera continually takes pictures and your hardware must keep up 
with it or lose data (pictures or parts of pictures).

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.

Step three work out a method to grab the WHOLE frame into some local
storage in ONE go. 

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.

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

SN74ALVC7804 is 512 x 18bit FIFO, just about one line of data

NXP LPC2141FBD64 is the SMALLEST device in the range having 8k SRAM and
2K endpoint RAM and NO DMA.

The chances of data loss are immense, any delay due to host being busy
or stuck in somebody else's driver wait loop will cause data overrun.
 
> I want to capture images and send them to the pc over USB...
> 
> In your opinion is possible to implement this project(with this chips)??
> or have you any suggestions?

Go do some research on how cameras work and come back when you know
how many frames at a time you want to grab.

 
> Best Regards,
> Edoardo
>   
> 
> 
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.EmbeddedRelated.com



-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<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

On Nov 2, 3:37=A0am, Paul <p...@pcserviceselectronics.co.uk> wrote:
> In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dn...@giganews.com>, cerbero85
> @n_o_s_p_a_m.gmail.com says...
>
>
>
> > Hi all. I'm making a project with a low-resolution camera and I want to
> > transmit the captured frames over an USB channel.
>
> Sounds like a student project.
>
> Do you want a single frame, every second or third or... frame or all
> frames?
>
> The more frames you want the more hardware you will need in your
> device and host, dedicated to image storage.
>
> > The camera is an Omnivision CMOS with 400x400pixel resolution(it uses a
> > bayer pattern) and 10/8 bit Raw output.
>
> > I saw the CMUcam project and if was possible i would make a similar
> > project.
>
> > I thought I'd use the following chips: Camera CMOS + FIFO buffer(Texas
> > Instruments SN74ALVC7804) + Microcontroller ARM7(NXP LPC2141FBD64)
>
> I doubt it. Cameras are NOT like memory or disk drives, so the camera
> does not take a picture and hold it witing for you to read it.
>
> The camera continually takes pictures and your hardware must keep up
> with it or lose data (pictures or parts of pictures).
>
> 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.
>
> Step three work out a method to grab the WHOLE frame into some local
> storage in ONE go.
>
> 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.
>
> 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
>
> SN74ALVC7804 is 512 x 18bit FIFO, just about one line of data
>
> NXP LPC2141FBD64 is the SMALLEST device in the range having 8k SRAM and
> 2K endpoint RAM and NO DMA.
>

One idea I have is to stuff data in a 256K bits Dynamic RAM.  They are
16 or 18 pins DIP, most likely free.  As long as you keep stuffing it,
no worry about losing data.  Most people, like me, should have some in
the garage.

Thanks for the replies

>In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dnZ2d@giganews.com>, cerbero85
>@n_o_s_p_a_m.gmail.com says...
>
>Sounds like a student project.

Yes.. and I have available a low budget.

>
>Do you want a single frame, every second or third or... frame or all 
>frames?

Full frames (400x400 pixel to 30FPS)


>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.

The A/D convert works at 8MHz.

So the size of one frame is:  400 x 400 x 1byte = 160KB 


>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

>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?

>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
>
>SN74ALVC7804 is 512 x 18bit FIFO, just about one line of data
>
>NXP LPC2141FBD64 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)

and

Microcontroller Stellaris LM3S3748 50MHz  64kB SRAM and 128KB ROM and DMA

You know a microcontroller with USB that support UVC?
	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Nov 3, 5:33=A0am, "cerbero85" <cerbero85@n_o_s_p_a_m.gmail.com>
wrote:
> Thanks for the replies
>
> >In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dn...@giganews.com>, cerbero85
> >@n_o_s_p_a_m.gmail.com says...
>
> >Sounds like a student project.
>
> Yes.. and I have available a low budget.
>
>
>
> >Do you want a single frame, every second or third or... frame or all
> >frames?
>
> Full frames (400x400 pixel to 30FPS)
>
> >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.
>
> The A/D convert works at 8MHz.
>
> So the size of one frame is: =A0400 x 400 x 1byte =3D 160KB
>
> >Step three work out a method to grab the WHOLE frame into some local
> >storage in ONE go.
>
> I found this: AL422B FIFO =A0384K x 8bit
>
> >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?
>
> >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
>
> >SN74ALVC7804 is 512 x 18bit FIFO, just about one line of data
>
> >NXP LPC2141FBD64 is the SMALLEST device in the range having 8k SRAM and
> >2K endpoint RAM and NO DMA.ust
>
> I found this chip:
>
> FIFO Averlogic AL422B is 384K x 8bits (is possible store two frames)
>

We are heading in the right direction, in terms of memory type and
size.

But I am not sure FIFO is the right structure for this.  You need to
buffer the USB latency and you can't just FIFO the USB bus signals.
You really need random access memory for the micro.

> andust
>
> Microcontroller Stellaris LM3S3748 50MHz =A064kB SRAM and 128KB ROM and D=
MA

If you need external memory anyway, 1k internal sram is as good as
64k.

>
> You know a microcontroller with USB that support UVC?

At90usb82 (8k), At90usb162 (16k), Atmega32u2 (32k), At90usb646 (64k)
and At90usb1287 (128k) are those I am familiar with.

Also, LPC1768, NVC120, STM32somethng are possible alternatives.

>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.EmbeddedRelated.com

In article <xLadnfBSLN8Ky0zRnZ2dnUVZ_uydnZ2d@giganews.com>, cerbero85
@n_o_s_p_a_m.gmail.com says...
> 
> Thanks for the replies
> 
> >In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dnZ2d@giganews.com>, 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 (160000 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 TDA8703 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
> >
> >SN74ALVC7804 is 512 x 18bit FIFO, just about one line of data
> >
> >NXP LPC2141FBD64 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 LM3S3748 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          | paul@pcserviceselectronics.co.uk
<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

Further thoughts.. (should not post with heavy head cold)

In article <xLadnfBSLN8Ky0zRnZ2dnUVZ_uydnZ2d@giganews.com>, cerbero85
@n_o_s_p_a_m.gmail.com says...
> 
> Thanks for the replies
> 
> >In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dnZ2d@giganews.com>, cerbero85
> >@n_o_s_p_a_m.gmail.com says...
> >
> >Sounds like a student project.
> 
> Yes.. and I have available a low budget.
> 
> >
> >Do you want a single frame, every second or third or... frame or all 
> >frames?
> 
> Full frames (400x400 pixel to 30FPS)
> 
> 
> >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.

As you said it was an Omnivision CMOS camera in first post, it
more than likely has digital o/ps unless you are using the older
analog parts. So the data formatting becomes important.
 
> The A/D convert works at 8MHz.

Is this the one inside the camera sensor?

I would expect at least two of them unless you have a monochrome 
sensor.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<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

On Nov 3, 3:24=A0pm, Paul <p...@pcserviceselectronics.co.uk> wrote:
> In article <xLadnfBSLN8Ky0zRnZ2dnUVZ_uydn...@giganews.com>, cerbero85
> @n_o_s_p_a_m.gmail.com says...
>
>
>
> > Thanks for the replies
>
> > >In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dn...@giganews.com>, 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 (160000 pixels)

So, you (OP) are getting into mpeg domain.  It's probably cheaper and
easier to get a mpeg encoded camera module.

On Thu, 4 Nov 2010 11:39:21 -0700 (PDT), linnix <me@linnix.info-for.us>
wrote:

>On Nov 3, 3:24&#4294967295;pm, Paul <p...@pcserviceselectronics.co.uk> wrote:
>> In article <xLadnfBSLN8Ky0zRnZ2dnUVZ_uydn...@giganews.com>, cerbero85
>> @n_o_s_p_a_m.gmail.com says...
>>
>>
>>
>> > Thanks for the replies
>>
>> > >In article <g8-dnVaMyNriiVLRnZ2dnUVZ_q2dn...@giganews.com>, 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 (160000 pixels)
>
>So, you (OP) are getting into mpeg domain.  It's probably cheaper and
>easier to get a mpeg encoded camera module.

Not in stock, but I did get (and play with) their earlier version C328.
<http://www.electronics123.com/s.nl/it.A/id.3010/.f> and there's an SPI
flavor as well. Not sure what the max frame rate is ...

-- 
Rich Webb     Norfolk, VA

Hi, all. 

I changed the project for the university and now I have some time to
continued this (for my personal interest). 

The specifications of the camera are summarized below:

- 400x400 pixel
- 30FPS
- output 10/8bit (I decide to use only 8bit)
- the output format is RAW (the software make the color interpolation)

So the one frame have a 400x400x1byte = 160KByte (RAW Image)

At 30fps that is 4.8MByte per second = 38.4Mbps


My goal is find a chip that send the camera's frame to the pc over USB2.0
.
For this I understand (thanks Paul and linnix) that is not possible send
directely the frame to USB for the time latency.

So I need a buffer (FIFO or DRAM).


I have read some tutorial of usb protocol, but I don't understand very
well.

If I use the USB in Full Speed (12Mbps) isochronous mode, a device can send
a maximum of 1023 Bytes during a  "frame" (each "frame" is 1ms).

The camera produce data to 160 KByte, so the job of the buffer is store the
data and then sent it to the usb in packets of 1023 Byte each 1ms, is
right??

In your opinion why some projects (for example CMUcam and AVRcam) use the
RS232 connector for connect the camera to a pc and not usb?


	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com