CMOS camera to USB

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.

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.

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

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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

Yes.. and I have available a low budget.

Full frames (400x400 pixel to 30FPS)

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

I found this: AL422B FIFO 384K x 8bit

This I didn't understand?

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

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.

MA

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

64k.

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

Also, LPC1768, NVC120, STM32somethng are possible alternatives.

So think about the data flows.

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

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

Does not seem fast enough, also consider a TDA8703 8but 40MHz and very cheap.

In Monochrome, it is definitely 160,000 PIXELs, number of bytes per pixel is determined by the formating of the sensor.

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

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.

and

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.

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
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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.

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
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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

For a monochrome image yes.

USB2.0

If nothing else look at USB slave device micros or even FTDI FT42232H or whatever their latest offering is as this has a FIFO interface and claims to be able to acheive full 480Mbps data rates.

Look at USB 2 and High Speed (480 Mbps), in whic the frame time is somewhat quicker.

Yes that is teh job of the FIFO. But you will get behind and not acheive

30fps at 12Mbps USB.

USB was not around for the original CMUcam most of these cameras cannot achieve 30fps.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

Paul skrev:

You can do this with a modern ARM processor, like the AT91SAM9G45. It has both High Speed USB as well as a camera interface.

You can get a SAM9G45 CPU module from

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

Paul skrev:

You can do this with a modern ARM processor, like the AT91SAM9G45. It has both High Speed USB as well as a camera interface.

You can get a SAM9G45 CPU module from

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

Yes, that will work. Just want to point out that this is a 400MHz processor in 324 balls BGA.

A small FPGA + SRAM (or SDRAM) + USB PHY would work, but not the easiest solution to implement without prior experience.

cerbero85

time to

interpolation)

over

That is why I provided a link to a DIMM Module w flash and DRAM Ulf

--
Best Regards,
Ulf Samuelsson