я может чего не понимаю,

но куда они в atmegе8 девают столько данных???
пусть даже QCIF 176 x 144, пусть по 8 бит на пиксел, это все равно 25кб данных.
через rs232 и то почти 3 секунды пропихиваться будет, а матрица вроде кмоп - бегущий затвор соответственно => экспозиция пикселов завязана на считывание => движущиеся объекты сфотографируются как попало.
имхо работать не дожно.

или мегой они просто кадр на лету анализируют, типа средняя координата пятна опр цвета?
но все равно 176*144*27=684288, при 16 МГц ~ 20 опрераций на точку - особо не разбежишся, хотя посчитать среднюю координату наверное можно...

Лучше бы это обсуждать в другой ветке, можетт модераторы перенесут. Но я так понял из статьи, что речь идет не о видеоизображении как таковом, а о регистрации центров движущихся цветовых пятен заданного пользователем цвета (до 8 цветов и до 8 объектов), типа датчика движения. А тут большой пропускной способности не надо, главное определить, в какую сторону смещается пятно.

Вот и перенёс. Надеюсь все будут придерживаться этого правила (отдельная мысль - отдельная тема).

AVRcam_fullEntry_A3694.doc
page 1
A low-cost image processing engine capable of visually tracking eight objects of eight different user-defined colors, at 27 frames per second…


AVRcam_fullEntry_A3694.doc
page 5

"Only one line of pixels is acquired and sent per frame. Thus, it takes around 4 seconds to acquire and output a complete frame of data. This flow is shown in Flowchart 1."

Как я понял со своим слабым аглицким, протокол упрощен до предела, используется только 4 бита из 8 при сэмплировании и в каждом фрэйме передается только одна линия. Так что для робота может и сгодится, а так - "баловство все это".

Дело в том что это устройство используется для слежения за обьектом (наверно в любительском роботе) а не для посылки картинки фрейма в компютер . Но если добавить ОЗУ и немного помудрить над кодом - все станет на свои места .

гуд лак)