PaulS:
Can I use the OpenCV libraries in the chip?
If you download the Arduino version, sure.
Paul - you shouldn't tease someone like that - I'm pretty certain that OpenCV has not been ported to the ATMega line...
flotschie:
I never programmed a chip like Arduino before, my knowledge is limited to "normal" software programming.
What I don't understand is how you claim to know "normal software programming" - yet don't understand the concepts of RAM, how much space you have and can use, the fundamental differences between the ATMega328 microcontroller (in the context of memory - ie, SRAM vs Flash vs EEPROM) and a regular PC, etc.
I mean - if you did - you would quickly realize and understand what kind of limitations you are working with, and why OpenCV will not fit on an Arduino...
flotschie:
I want to connect a chip (like Arduino) with a mini camera. The chip should analyze the video of the mini cam in real time (very simple picture-diff algorithms)
Doing per-pixel analysis, while simple (even for an Arduino), still requires something called a buffer (a part of RAM) to do the analysis on; this buffer will be limited by the total amount of RAM available to you as a programmer to use. In the case of the ATMega328 (UNO) - that is 2K; for the Mega, it is 8K - though it is possible to expand this considerably - for instance: http://ruggedcircuits.com/html/megaram.html (you can't do this with an UNO, unfortunately). In the middle (kinda) would be the ATMega644 - which has 4K).
If you need to analyze an entire frame - you need to be able to store that frame - because of the limitations of RAM, you may need to make compromises.
For instance, you mention a 64 x 64 resolution; if you wanted to analyse 3:3:2 RGB (256 colors) - you would need one byte per pixel - or 4K (this buffer is called a "framebuffer" - since it stores one "frame" of the captured image that you will work with); well - that won't work on an UNO, but it could work on a Mega. The higher your resolution needs, though (both in pixels and in bits-per-pixel), the more SRAM you'll need, and the less you'll have for the variables in your code. And you need some for the variables, otherwise you'll have nothing to run your calculations with!
Also realize that you don't have to analyse an entire frame - you can do analysis on portions of a frame - either sectors (say 8 x 8 pixels at a time) or lines (horizontal/vertical/diagonal); these options can be useful for motion tracking, as well as for blob tracking (and perhaps simple shape recognition). Keep that in mind; perhaps you can think of an algorithm that would fit on an Arduino UNO?
Regardless of all of the above - you need to be able to get the image on to the microcontroller. Most small cameras you see out there (not all) have jpeg-only output. What you need to find is a camera that has RAW byte format output (and preferably one that you can specify how that output is to be delivered). Such camera modules exist, but they aren't as common on the hobbyist market as jpeg output camera modules. Hopefully whatever camera module you use is SPI compatible - it will make things easier.
A couple of other options also exist. One, you could use a lower resolution camera, such as one from these guys (not sure if they are still in business?):
http://66.147.244.149/~centeyen/
..or, you could use the sensor from an optical mouse (greyscale only, though).
Another alternative would be to use something like the CMUCam (which does the processing on-board - perhaps not something you want) - or the AVRCam - which is like the CMUCam, but uses an ATMega8:
http://www.jrobot.net/Projects/AVRcam.html
...indeed, that there might provide you some ideas, as the ATMega8 is pin-compatible with the ATMega328 on the UNO...
Another option:
Although again, this is a black and white only solution - but it might again give you some ideas.
In short, what you want to do is possible - given certain limitations (sometimes, very severe limitations). Also realize that if you implement this, likely the Arduino won't be able to do much else beyond the image processing and analysis (it's going to chew through its cycles and SRAM just doing that). So you will likely have to look at such a system as one unit (much like the AVRCam and CMUCam are designed - they both are actually using another microcontroller embedded to perform the process they are designed for - other microcontrollers communicate and issue commands with the microcontroller on the camera module).