CCD camera control with AM3352

Javier,

AM3352 doesn't have a camera interface to interface image sensors. Also it doesn't have any DSP or hardware encoder support for video encoding. So, both from a cost and functionality perspective, I think DM335 or DM365 will be a good option which will come under less than 10 dollars.

You can check the Appro DM365 based reference design for evaluation.

http://www.appropho.com/NewWeb/Product_All.php 

Javier Herrero de la Cal said:

Hello,

I just would like to know if I can easily control a CCD camera with a AM3352 processor. The price of this processor match me very good for my application. I have to receive the video images from a CCD camera, compress them and send them by bluetooth. I have though in using the tms320dm335 but this system will be used in a consumer electronics product and I need the cheapest processor for this application. I also want to know your advice for make this project. What would you use? If possible, under the 10 dollars per processor.

Thanks for your attention and regards,

Javier

I have looked in to this kind of situation from a robotics perspective so my answer is based only on my opinion of what your result might be if it was a robotics ( telepresence ) project.

I would be looking at USB native ARM processors to start.  The processor you are considering does ( my opinion here ) too much of the conversion of a streamed video image ( pre-encoded to 2 wire RCA connector image ) for a simple CCD to BlueTooth out.

Using a memory map and a simple CCD IC interface to do the scanning of the CCD data, most of the ( over 4 MHZ speed ) Stellaris processors could read, convert to JPG and use USB out ( slave mode with Blue Tooth adapter IC ) to connect with the paired system ( phone/pc/tablet ) to send the image over it.

One issue i have had ( and have to postpone for a while to resolve ) is getting several images and possibly sound and stream them ( AVI format ) as I seem to keep loosing the packets with the current setup.  More memory for what I have been working on may resolve it.

The issues I can see going with this aproach is that the processor you do use needs to do the following

1) read/scan the CCD and store in to some memory

2) encode in to some format ( possibly just JPG as it would cut down coding to include more formats )

3) send via bluetooth ( simplest result I have achieved is with a USB bluetooth IC directly wired on to a USB line as line out and a cheap dongle on the PC side )

4) have the pc/tablet/phone paired with the bluetooth so that it can know what/when to recieve.

using this page and checking the box for USB and lowering the price per unit slider ( as an example MPU to look at ) there are 16 possible choices

http://www.ti.com/lsds/ti/microcontroller/32-bit_c2000/product_search.page

I will note, i did not look in to the input/output available, power reqirements or memory.  I will once again say the reasoning for looking in to USB included is that with what experience I have had, it was simpler and easier to use pre-configured USB out from a MPU for BlueTooth.

Hope this points you in the right direction,

Eric

Eric,

1. What is the resolution and frame rate of the CCD sensor that you are planning to support? 

2. How are you planning to interface the sensor to the host? Is it USB camera or a raw sensor?

I was posting my opinion over how best to look at the issue Javier was having finding a MPU for video processing over blue tooth.

What I had was a direct IO to a 320x200 IC ( no longer available last time I looked for a replacement IC from the vendor ) and with a fairly cheap USB/BlueTooth dongle did manage to have one on a host pc and one on the device an send single JPG files to the PC.  Life has since gotten in the way and processors and MPUs ( like the new ARMs on the launchpad boards ) are now available with more built in ram, addressable IO and built in USB with out having to " fake " it with memory maped IO signals like was done for the early 8088 com ports.  What I was doing was trying to set up a form of telepresence ( think mars rover, but sending clips too, and before you ask, no, not associated with any space program ).

  From the brief description from Javier, they were looking for something similar and consumer grade, robust for operations and low in cost of production.  Currently I am still waiting on Stellaris LM4F120 LaunchPad Evaluation Board for another project that may lead back in to me looking in to this one.

Eric

Eric,

AM335x is generally used for tele presence applications. But I've those questions to understand your requirements clearly and suggest a better alternative. The issue with AM335x is that its not really meant for doing multimedia processing. If you are have a CCD sensor which will send raw data, depending on the resolution you've to capture the data at a faster rate.

Let's say you have a VGA (640x480) resolution RGB16-bit sensor and would like to capture at 30 fps. This essentially means that you've to capture 640x480x2x30 = 18432000bytes ~= 17MB of data per second. It will be nearly impossible to read this much data using GPIO pins. To solve this issue, many of the other silicons has a camera interface which will automatically read such data and write into memory using a DMA. Depending on how you configure the camera controller, it will capture the frame and raise an interrupt once the whole frame is captured. 

At the same time, if you are attaching a USB camera, it will be easier to capture using AM335x as you don't need a camera interface. 

Then comes the next problem. You need to encode the stream as a video or as multiple JPEG images. This can only be done using ARM core alone in AM335x or using a hardware h.264/mpeg4/jpeg encoder in other silicons. If you are not using ARM core for anything else, then ARM can do the encoding up to a certain resolution. I'm not sure about the performance numbers. 

Another point you should be considering is that the available bluetooth bandwidth. If you use Bluetooth, the best bandwidth that you've be able use for you application will be less than 2mbps. So if you don't use a good quality encoder, you won't be able to limit the bandwidth usage. 

So it all depends on the camera sensor resolution and performance requirements.