roboforum.ru

.
TGA130V10 - модуль с установленной камерой OmniVision OV9650



можно приобрести в Терраэлектронике (на данный момент цена около 950 руб.)

Камера от знаменитого производителя, столь сложная для любительского монтажа (BGA-исполнение), смонтирована на плате с разъемом 2.00mm header, на борту установлен 2.5V LDO regulator, необходимый для аналогового питания, и к ней требуется подвести питание для процессорного ядра (1.8V) и питание ввода/вывода (2.5-3.3V).

Введение
Предлагаю вашему вниманию уникальный опус, в котором я поделюсь бесценным опытом работы с камерой, на даташите которой производитель отлично отдохнул. Я нигде в инете не нашел руковдоства к действию даже на английском языке, максимум конкретные вопросы на форумах. Единственный источник полной информации - тех. поддержка OmniVision
Даташит не только неполноценный, это еще цветочки, в нем полно грубейших ошибок, природа которых заключается в небрежной копипасте. Много информации можно почерпнуть из даташитов на близжайшие модели камер и обнаружить, например, что такой же регистр выполняет совершенно другие функции.
Я подключил камеру к отладочной плате Olimex LPC-H2103 с установленным на ней МК NXP LPC2103. Это 32-битный МК архитектуры ARM7, работающий на частоте 60МГц. Моей целью стояло получение изображения разрешением QQCIF (88x72) в формате RGB555. МК имеет очень мало памяти, поэтому я получаю в память строку из кадра, передаю ее на комп по UART, затем из следующего кадра получаю следующую строку и т.д. Разумеется, сцена перед камерой должна быть статичной
В статье я обязуюсь предоставлять исключительно достоверную информацию, иначе бы она не имела смысла, и несу ответственность за любую опечатку головой (ну... орфографические опечатки допускаются ). Обобщение фактов на другие модели камер оставляю вам. Если я в чем-то хоть чуть-чуть сомневаюсь, я это указываю.
Итак, дальнейшая информация получена мною в результате мучений и разнообразных экспериментальных иссследований в течение недели, проводившихся преимущественно методом тыка (о, хвала даташитописателям ! я могу часами их материть...).

Краткое описание
Прежде всего внимательно изучаем подробнейший документ на камеру (уникальная вещь !) и даташит Doc 02, а лучше новую версию 1.91
Камера может тактироваться ШИМ-сигналом частотой от 10 до 48 МГц. Изображение выдается на 8-битную шину согласно стандартным сигналам горизонтальной (HREF, HSYNC) и вертикальной (VSYNC) синхронизации и стробирующему пиксельному сигналу PCLK, частота которого может быть настроена делителем в регистре CLKRC(0x11). Сразу после включения камера начинает выдавать картинку в формате YUV (CCIR601, 8-bit Cb Y Cr Y), наиболее хорошо форматы описаны в даташите на OV6620, в котором нас интересует Table 4 и Figure 3 (нижний тайминг). Все настройки камеры доступны посредством записи/чтения 170 8-битных регистров (не обольщайтесь) через интерфейс SCCB, который, смею вас заверить, полностью совместим с I2C. Ввведение OmniVision'ом якобы собственного стандарта всего лишь трюк для избежания лицензионных требований от компании изобретателя I2C - компании Philips, не более. Настройки/регистры наиболее полно описаны в даташите на OV9660.

Схемотехника
Распиновка выводов с камеры на 0.5mm pitch connector ("гибкая лента") приведена в Doc 04, а схема самой платы, соединяющей камеру с интерфейсным разъемом в Doc 03. И, разумеется, тут тоже ошибки. На самом деле, все нормально, пины Y7-0 подключены к выводам камеры D9-2 соответственно. Заметьте, что D1-0 не выведены вообще.
Схема моей платы выполнена в Eagle PCB 5.6.0, я вырезал все лишнее (подключения сервоприводов и т.п.), вот сами файлы, а у кого нет игла, скриншоты:


а вот как оно в железе выглядит:

После того как я угробил пару камер, я стал очень бережно относиться к ним, поэтому не удивляйтесь "забронированной" камере
Черным проводом я отдельно провел XVCLK, ...<бредятина>... - позже я выяснил, что это полный бред и совершенно нет необходимости
Сама камера практически впритык к разъему подключена. Возможно все это покажется вам параноидальным, но я столкнулся с наводками/помехами. Изначально то я, конечно, 30см шлейфом соединил (я ведь камеру на схват робота устанавливаю, а плата в основании находится), но при этом камера заводилась на раз через раз и только с плясками с бубном.
Сверху подключен JTAG-адаптер Signalyzer DT-USB-SLITE, с помощью которого я прошиваю МК и провожу отладку в чипе
Регистр IN74AC374N (аналог КР1554ИР23) защелкивает данные по стробу PCLK и хранит их до следующего строба, иначе МК может и не успеть прочитать их, ведь фиг знает, сколько они удерживаются после строба.
Пины камеры RESET и PWDN внутренне подтянуты до нуля, поэтому в принципе нет необходимости подключать их, т.к. в камере заложена возможность программного сброса и ухода в спящий режим (!не проверено!)

Программная часть (software)
Самая интересная и кульминационная часть, не так ли

Полностью рабочий пример на C, составленный в виде проекта C++ Project на Eclipse IDE для GNU GCC и Yagarto GNU Toolchain (GNU ARM Eclipse Plug-in для Eclipse), и файл Launch-конфигурации (который можно импортирвоать в проект) для отладки в OpenOCD (Zylin Embedded CDT plugin). В проекте присутствуют сгенерированные автоматически эклипсом make-файлы, поэтому в принципе можно вручную собрать Программа выводит в UART картинку в разрешении QQCIF попиксельно (3 байта, GRB). Полученные данные можно вставить в bmp-файл и узреть BMP-файл содержит заголовок, опционально таблицу цветов (у нас нет) и собственно сами данные. Строки идут снизу вверх, данные начинаются со смещения 0x36, причем цветовые составляющие пикселя идут в порядке GRB, а не RGB. Создаем в виндовом пейнте пустую картинку с разрешением 88x72 и сохраняем в формате "24-разрядный рисунок bmp". Потом WinHEX'ом вставляем по смещению 0x36 raw-данные, полученные по уарту (это смещение хорошо видно, начиная с него идут FF FF FF ... (белые пиксели), вот поверх них и записываем), сохраняем, и вуаля, получаем перевернутую картинку
После подачи на камеру тактового сигнала она начинает выдавать изображение, но не совсем сразу. В любом случае крайне рекомендуется делать сброс. Устанавливаем RESET в 1, ждем хотя бы 5мс, включаем ШИМ-сигнал, ждем 5мс, устанавливаем RESET в 0, ждем хотя бы 1000мс (можно и меньше, но если включены всякие авто-штучки типа AWB, ABLC, AGC, AEC, то требуется еще время, чтобы картинка подстроилась под освещение, цвета и т.п.), после чего можно принимать изображения.
Подробно I2C-взаимодействие с ней раписано в этом даташите. Slave ID камеры 0x60 (при записи 0x60, при чтении 0x61), subaddress - адрес регистра, data - значение регистра.
По регистрам разбросаны самые различные настройки, которыми овладеть полностью может только мегаспец в области видео (если вы думаете, что вам не придется в них разбираться исходя из того, что вы всего лишь хотите получить хоть какое-то изображение, а всякие настройки по умолчанию заданы самым оптимальным образом и нет необходимости их трогать, то спешу вас разочаровать ). Значения разрядностью более 8 бит разбросаны по разным регистрам. LSB (less significant bit) - младший значащий бит, MSB (most significant bit) - старший значащий бит. Опции могут быть взаимосвязаны, например, в одном регистре надо установить бит, включающий функцию, а в другом, а возможно и третьем, задать необходимые значения.

Ну а теперь крайне ценные руководства и факты...

• Первым делом выясните, с каким чипом и его версией вы работаете. Да, да, мне попался чип с более новой версией. Для этого прочтите регистры PID(0x0A) и VER(0x0B) (не из даташита, а из самой камеры). На сайте TechToys находится даташит версии 1.3, где PID=0x96, VID=0x50, я же обнаружил, что у меня VID=0x52. Я просто загуглил "omnivision pid 96 vid 52" и нашел даташит версии 1.91. Сравнил оба даташита, в новом исправили как мелкие косяки, так и удалили некоторые настройки регистров и добавили новые. Вообще, с каждой версией даташита (а может и чипа тоже), раскрываются регистры, ранее считавшиеся зарезервированными (RSVD), просто даташитописателям лень все документировать сразу.
• В начале камера выдает всякое барахло. Запишите в регистр OFON(0x39) значение 0x43 (и никакое другое!), если хотите увидеть осмысленное изображение Смысл этого регистра в разных даташитах разный и ни разу не отражает его истинное предназначение. Условно назовем его регистром, включающим камеру
• Сигнал VSYNC ведет себя странным образом (!есть сомнение!). Я как то хотел подсчитать, сколько строк выдается в кадре, и пришел к такому выводу, что в течение кадра VSYNC выдает положительные импульсы, возможно из-за наводок. Причем, это не мешает приему изображения, если синхронизироваться этим сигналом, а во время приема кадра (т.е. пока VSYNC=0), не обращать на него внимания. Видимо вблизи начала кадра этот сигнал ведет себя корректно (ведь href и, возможно, pclk отсутствуют, что и навело меня на мысль о наводках)
• Настройка частоты PCLK. Регистр CLKRC(0x11). BIT[6] и вправду устанавливает частоту PCLK равной входной тактовой частоте XVCLK, значения остальных битов более не виляют на частоту (!не проверял последнюю часть утверждения!). BIT[5:0] - делитель, позволяет уменьшить частоту PCLK до 32 раз меньшей входной, значение расчитывается согласно тут же приведенной в описании формуле. BIT[7] - если 0, то PCLK еще в 2 раза уменьшается, если 1, то нет.
• Получить изображение в формате RGB555 мне не удалось. Я установил BIT[2] в COM7(0x12) и BIT[5:4] в 11 в COM15(0x40). Я плюнул на него, ведь фиг знает, регистры то напутаны могут быть, и лишь одному Онотоле известно, куда что записать, чтобы камера выдавала данные в RGB555. Пока что я смирился с этим фактом и декодировал YUV (CCIR601, 8-bit Cb Y Cr Y, тобишь 4 байта на пиксель), которым она выдает по умолчанию. Это был триумф, когда я впервые получил осмысленную картинку. Обычно я в таких случаях подпрыгиваю до потолка, ударяюсь башкой и мне ее сносит, я долго бегаю по квартире, вопя "оно заработало !!! фак мой моск !!!", но бессоные ночи меня вымотали, и тем более я опаздывал в бассейн. Я просто вздохнул с облегчением
• Выбор разрешения. Это самое веселое Регистр COM7(0x12) содержит биты, устанавливающие нужное разрешение. Кажется, что все очень просто, устанавливаем нужный бит и камера начинает выдавать изображение с соответсвующим количеством строк и пикселей и соответствующими таймингами. Но не тут то было... Во-первых, биты напутаны и не соответствуют заявленным разрешениям и даже вообще банальной логике. Я установил бит QCIF, но камера при этом стала выдавать QQCIF, причем изображение полосистое и растянутое (количество строк в 2 раза больше, как в QCIF), происхождение полос очень похоже на режим прогрессивного скана. Я решил воспользоватсья предлагаемым (а точнее даже требуемым) для QQCIF пропуском строк в регистре COM1(0x04), установив BIT[3:2] в 01 (строки пропускаются в буквальном смысле, т.е. href=0 на пропускаемой строке, кстати, это может оказаться весьма нелишним временем, если вы обрабатываете изображение в реальном времени). Вуяля, изображение стало пропорциональным, но полосы остались. Я тогда выбрал разрешение CIF и получил картинку в 2/3 раза меньшую (!не помню точно, помню лишь, что тоже ерунда была!), и тогда я наконец попробовал QVGA, которое мне выдало изящную картинку - без полос и с насыщенной гаммой цветов. Нетрудно сообразить, что разрешение и картинку определяют несколько различных регистров в совокупности, и тупо сидеть перебирать значения 170 регистров просто нереально, и я забил. Мне как раз нужно было QQCIF и я его получил
• Магические установки от Девида Блейна. По умолчанию камера выдает жутко дерьмовое изображение (хотя бы уже полосы, перечисленные выше в формате QCIF или, вернее, QQCIF). TechToys предлагает Breakout board compatible with 3.5" TFT color LCD module for life video, в котором установлена наша плата с камерой. Там я скачал Example code for Microchip PIC18xxx & CMOS camera (ver. 19012009). Из camera/ov9650.c, camHwInit я извлек эти священные установки регистров, покрытые мраком неизвестности. Это настолько таинственные настройки, что даже в комментариях к ним написаны недоумевания. Видимо автор вошел в транс, когда писал их, но выйдя из него, он не смог объяснить, что он произвел на свет. Благодаря им, дерьмовое изображение стало шикарным - полосы исчезли, цвета насытились, яркость увеличилась, единственный минус - на неосвещенных участках шум из розовых, красных и синих пикселей, а идеальная картинка только при отличном освещении. Итак, там устанавливаются практически все регистры камеры: различные авто-штучки, настройки экспозиции, gain-control, фильтры, шумоподавление, гамма-коррекция, коэффициенты матриц и прочее, причем половина из них устанавливается в значения по умолчанию, что далеко не самое странное, так помимо прочего записываются еще и зарезервированные регистры. Я закомментировал зарезервированные регистры, наивно полагая, что ничего не изменится, но не тут то было Я сделал лишь немного изменений, касающихся моих собственных предустановок, все остальное я пробовал ковырять, но мне не удалось постичь их магию, и я оставил как есть.
• Непредсказуемое влияние одних установок на другие.
  Пример 1. Магические установки привели к тому, что изображение сдвинулось вправо, в начало добавиллись две полосы, первая белая, вторая - утемненное изображение края, и, соответственно, две послыедние полосы уехали за край Я стал искать, какая из установок приводит к такому, я надеялся, что где-то нечаянно лишний бит устанавливается или значение какого нить зарезервированного регистра, и я просто удалю эту установку, но не тут то было ... К данному смещению приводит включение функции "White-pixel erase" в регистре COM22(0x8C). Если не включать, смещение исчезает, но картинка с шумами. Вот такой вот подлый шантаж
  Пример 2. Вертикальный переворот изображения (VFlip enable в регистре MVFP(0x1E)) приводит к тому, что появляются жуткие артефакты в верхних (или нижних, смотря каких понятий придерживаться) строках. Переворот мне понадобился, потому что по умолчанию камера выдает перевернутое изображение. Что ж, ладно, фиг с ним. Буду работать с перевернутым.
• В виду выше сказанного, поинтересовался я, а какие действительно значения по умолчанию содержатся в регистрах после старта работы камеры ? Все 170 голубчиков вывел в уарт и сравнил. Выяснилось, что регистры 0x20-0x23 содержат отличные от умолчания значения. Вот так вот
• При JTAG-отладке, т.е. когда вы прямо в чипе будете по шагам выполнять программу и устанавливать различные брейкпойнты, будьте крайне осторожны. Думаю, достаточно очевидно, что при пошаговом выполнении замораживвается толкьо выполнение инструкций, но периферия работает в реальном времени, т.е. таймеры не замораживаются, передача по уарту не приостанавливается, поэтому не получится пошагово вмешаться в процесс синхронного приема данных с камеры и получить валидное изображение. НО! Более того. Даже если вы свободно "проскочите" синхронный код (например, дотопаете шагами до него, потом поставите брейкпойнт на его последнюю строку, и нажмете Resume, код свободно выполнится, а потом встанет на брейпоинте), то в этом случае он будет выполняться медленнее, потому как отладчик сканирует код и ждет срабатывания брейкпоинта (спецы, возможно, меня подправят, я не сильно разбираюсь в этом, а всего лишь суть объясняю).
• gcc даже при отключенной оптимизации (-O0) как помешанный параоник оптимизирует код, поэтому будьте очень осторожны, когда на глаз прикидываете, сколько ассемблерных команд будет занимать та или иная строка сишного кода, в случае, если пишете синхронный код. Когда я читаю ассмеблерный листинг, у меня волосы дыбом встают, какой дикий код генерирует gcc

Вроде бы я все перечислил, позже еще чего-нить вспомню и включу в этот список

Оценка качества
Изображение, запечатленное цифровиком Canon PowerShot A95 (5.0 MegaPixels):
Изображение, запечатленное камерой OV9650 в разрешении QQCIF c магическими установками Девида Блейна, на объектив наклеена пленка (которую по идее надо снять) + стоит "стеклышко" от двд-бокса, поверх которого слой прозрачного скотча (возможно, без них качество лучше, но я предпочитаю безопасность):(пришлось конвертнуть в png, т.к. bmp запрещено настройками форума, но ни качество, ни цвета не пострадали)

Заключение
Если вы внимательно все прочитали, то скорее всего у вас отпало желание работать с камерами
Я писал это руководство, стремясь отдать дань общественности, другим авторам и всем тем, кто помогает друг другу и делится опытом. Надеюсь, что эта информация поможет вам резко сократить особо изощренный сексуальный акт, предшествующий успеху. Обращайтесь с вопросами, если таковые имеются, но советую поторопиться, потому как меня могут забрать в армию, откуда мне будет крайне затруднительно отвечать
Буду рад принять любые замечания, исправления и дополнения, которые буду по мере сил добавлять сюда (если, конечено, ограничения форума позволяют неограниченно редактировать это сообщение ).
Также просьба не флудить.

---
(c) Артем Писаренко, для roboforum.ru, 2010г.

А примеры изображений с камеры?

Обновил шапку. Добавлено изображение с камеры

Обновил шапку. Добавил рабочий пример на С для МК LPC2103.

Прилепил тему. Лишние сообщения потом потрем.

добавил: изображение с камеры могло бы получиться качественнее, если бы не проходило через наклеенную на объектив пленку (которую по идее надо снять), "стеклышко" от двд-бокса и слой прозрачного скотча на этом стеклышке. все это из соображений безопасности

замечание самому себе щас избавился от черного провода с экраном, тобишь вернул сигнал XVCLK обратно в шлейф и все работает. я тут почитал немного о согласовании линии передач. походу, все зависит только от длины провода (по крайней мере наибольшее влияние оказывает), а частота шим-сигнала не влияет, а влияет скорость переключения, т.е. фронт, как я и предполагал раньше, тогда у меня все сигналы равноправны

По UART изображение на ПК быстро не передать.
Если твой МК успевает читать из камеры весь кадр, то попробуй по USB его отослать.
Вот здесь я отписывал viewtopic.php?p=145301#p145301
У меня BlackFin BF537 продавливал через USB 160x120x60fps (160x120=38.4KB YUYV), то есть примерно 2МБайт/сек было. Платка довольно легка в работе, 8 проводов данных и несколько: WR,RD,TXE,RXF
в принципе достаточно дергать WR гогда байт готов.

да мне оно и не надо на комп передавать, это я в процессе отладки картинку смотрел, теперь я приступил к целевому использованию камеры...
но USB-платку возьму за заметку

кстати, единственный минус магических установок то, что неосвещенные участки зашумлены, а там где темнота, вообще жуткий шум из розовых, красных и синих пикселей, но он не по всему участку распределен, а располагается преимущественно по краям изображения, если темнота к краю примыкает. картинка идеальная только при отличном освещении.
вот пример

Нашел редчайший документ совершенно случайно: OV9650 Application Note.pdf от OmniVision. Он, конечно, многое объясняет, но такой же косячный как и даташит. Я по началу обрадовался, думал, что теперь то как следует настрою камеру... ага, фигушки...
Добавил в первый пост.

artymen писал(а):кстати, единственный минус магических установок то, что неосвещенные участки зашумлены, а там где темнота, вообще жуткий шум из розовых, красных и синих пикселей, но он не по всему участку распределен, а располагается преимущественно по краям изображения, если темнота к краю примыкает. картинка идеальная только при отличном освещении.
вот пример

image.png

Да, мне тоже OV9655 не нравятся, OV7725 получше будет

Выдрал установки регистров с проекта Video4Linux (V4L) из драйверов на чип m5602.
http://linuxtv.org/hg/v4l-dvb/file/a95a ... spca/m5602
Они обеспечивают гораздо лучшее качество изображения. Я подкорректировал немного (первым делом убрал slave-режим).

Код: Выделить всё • Развернуть

/* Enable double clock */
{OV9650_CLKRC, 0x80},
/* Do something out of spec with the power */
{OV9650_OFON, 0x40},

/* Set fast AGC/AEC algorithm with unlimited step size */
{OV9650_COM8, OV9650_FAST_AGC_AEC |
            OV9650_AEC_UNLIM_STEP_SIZE |
//            OV9650_AGC_EN |
            OV9650_AWB_EN |
            OV9650_AEC_EN |
            0},

{0xA1, 0x0}, // AECHM
{0x10, 0x22}, // AECHM

{OV9650_CHLF, 0x10},
{OV9650_ARBLM, 0xbf},
{OV9650_ACOM38, 0x81},
/* Turn off color matrix coefficient double option */
{OV9650_COM16, 0x00},
/* Enable color matrix for RGB/YUV, Delay Y channel,
set output Y/UV delay to 1 */
//{OV9650_COM13, 0x19},
/* Enable digital BLC, Set output mode to U Y V Y */
{OV9650_TSLB, 0x0c},
/* Limit the AGC/AEC stable upper region */
{OV9650_COM24, 0x00},
/* Enable HREF and some out of spec things */
{OV9650_COM12, 0x73},
/* Set all DBLC offset signs to positive and
do some out of spec stuff */
{OV9650_DBLC1, 0xdf},
{OV9650_COM21, 0x06},
{OV9650_RSVD35, 0x91},
/* Necessary, no camera stream without it */
{OV9650_RSVD16, 0x06},
{OV9650_RSVD94, 0x99},
{OV9650_RSVD95, 0x99},
{OV9650_RSVD96, 0x04},
/* Enable full range output */
{OV9650_COM15, 0x0},
/* Enable HREF at optical black, enable ADBLC bias,
enable ADBLC, reset timings at format change */
{OV9650_COM6, 0x4b},
/* Subtract 32 from the B channel bias */
{OV9650_BBIAS, 0xa0},
/* Subtract 32 from the Gb channel bias */
{OV9650_GbBIAS, 0xa0},
/* Do not bypass the analog BLC and to some out of spec stuff */
{OV9650_Gr_COM, 0x00},
/* Subtract 32 from the R channel bias */
{OV9650_RBIAS, 0xa0},
/* Subtract 32 from the R channel bias */
{OV9650_RBIAS, 0x0},
{OV9650_COM26, 0x80},
{OV9650_ACOMA9, 0x98},
/* Set the AGC/AEC stable region upper limit */
//{OV9650_AEW, 0x68},
{OV9650_AEW, 0xA0},
/* Set the AGC/AEC stable region lower limit */
//{OV9650_AEB, 0x5c},
{OV9650_AEB, 0x90},
/* Set the high and low limit nibbles to 3 */
{OV9650_VPT, 0xc3},
/* Set the Automatic Gain Ceiling (AGC) to 128x,
drop VSYNC at frame drop,
limit exposure timing,
drop frame when the AEC step is larger than the exposure gap */
//{OV9650_COM9, 0x6e},

{OV9650_ADC, 0x04},
{OV9650_HV, 0x40},

/* Enable denoise, and white-pixel erase */
{OV9650_COM22, OV9650_DENOISE_ENABLE |
    OV9650_WHITE_PIXEL_ENABLE |
    OV9650_WHITE_PIXEL_OPTION},

/* Enable VARIOPIXEL */
{OV9650_COM3, OV9650_VARIOPIXEL},
{OV9650_COM4, OV9650_QVGA_VARIOPIXEL}

Определения регистров здесь:

В первый пост пихать лень

Здравствуйте, artymen.
Волею судьбы занимаюсь подключением сенсора OV7670. Ваши изыскания отчасти помогли мне.
В свете сего появилось несколько вопросов по вашему проекту:
- вы уверены что у вас выложен полностью работающий проект т.е. исходники OV9650_LPC2103_example.zip?
- при работе вы использовали 8 битный формат YUV4:2:2 последовательность UYVY
что означает действие "main.c:191 U = ((temp0 >> (17-6)) & 0xC0) | ((temp0 >> 6) & 0x3F);" ? так и несмог понять
- (кстати:
"Пока что я смирился с этим фактом и декодировал YUV (CCIR601, 8-bit Cb Y Cr Y, тобишь 4 байта на пиксель), которым она выдает по умолчанию."
это как раз 4 байта на 2 пикселя - в вашей интерпритации это будет: Y1UV и Y2UV в одной выборке, возможно вам это поможет )

День добрый. Уже прошло много времени, я подзабыл все, но постараюсь ответить на все вопросы
1. да, уверен, я проверял
2. это связано со схемотехническими особенностями подключения шины камеры к микроконтроллеру, линии разбросаны как попало, это действие собирает биты воедино
3. да, я уже знаю. это объясняет часть несуразностей с настройкой разрешения

Вопрос: как реализовать на этой камере цифровой зум? Предполагаю что надо играться с режимами QVGA/QCIF и OutputFormatter. Но пока у меня нчего не получилось.

Использую вот эту отладку с камерой OV7670:
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... K:MEWNX:IT

Выдержка из ApplicationNote:

OV9650 windowing function can be implemented with the sub-sampling mode for the camera zoom
function. For example, if the preview image size is 160 x 120 (QQVGA), the camera can be set to
output QQVGA sub-sampling mode, then set to output QVGA mode (320 x 240) and use the
windowing function to capture center-quarter area (160 x 120) to implement the 2x zoom-in
function. Then, the camera can be set to VGA mode (640 x 480) or SXGA (1280 x 1028) mode, to
implement 4x and 8x zoom-in function.