Выведение изображения с камеры OV7670 на VGA монитор с использованием FPGA

Предисловие

Прочитав много увлекательных статей об интересных разработках под FPGA, таких как тетрис, радиопередатчик и другие, я тоже загорелся идеей сделать что-нибудь для души. Для этой цели мной была приобретена камера OV7670 и отладочная плата DE-1 фирмы Terasic с чипом Cyclone II фирмы Altera. Задачу поставил следующую: вывести изображение с камеры на VGA монитор. Для того, чтобы оправдать использование FPGA, я собираюсь сделать это на максимальной для камеры скорости. Должен отметить, что легче понять эту работу помогут знания в области электроники: знания интерфейсов VGA и I2C, представление о SDRAM памяти и т.п.

Введение

Данная статья не является исследованием, это, скорее, отчет о проделанной работе, в котором я постарался показать основную идею и наиболее интересные и сложные на мой взгляд места. По сложности этот проект следует за «поморгать светодиодом», но имеет огромный потенциал к расширению. В проекте намеренно не используются готовые IP-ядра и стандартные интерфейсы, так как проект изначально планировался как рукописный. Также это поможет немного выиграть по ресурсам и быстродействию. Надеюсь, эта статья будет интересна читателям, а желание увидеть себя на экране через «самодельную камеру» сподвигнет к изучению FPGA.

Проблемы и способы их решения

Для того чтобы понимать, что нас ждет, взглянем на железо и оценим, с какими проблемами нам предстоит столкнуться. Камера OV7670. Камера способна выдавать изображение разрешением 640х480 точек с частотой 30 кадров в секунду в формате RGB565. Для работы камеры необходимо подавать на нее клок частотой 24 МГц. Камера передает пользователю данные по 8 битной шине, а также стробы синхронизации VSYNC и HSYNC. Временные диаграммы работы камеры представлены на рисунке 1.

Рис.1

Информация о цвете передается за 2 такта побайтно. Упаковка данных в байты представлена на рисунке 2.

Рис.2

VGA монитор. VGA это аналоговый сигнал, поэтому подавать цифровые данные на его вход не получится. Но на борту DE-1 имеются 4-х разрядные ЦАП, их мы и задействуем для преобразования цифрового сигнала в аналоговый. VGA с разрешением 640х480 имеет частоту обновления 60 кадров в секунду. Необходимо выставлять данные на ЦАП с частотой 25.175 МГц, а также формировать стробы синхронизации VSYNC и HSYNC. Тайминги для VGA можно посмотреть здесь.

Становится ясно, что частота поступления данных с камеры и частота вывода данных на монитор отличаются, что исключает возможность прямого подключения. Выход из этой ситуации — использование кадрового буфера. Выделим в памяти две равные области: в одну будет записываться текущий кадр с камеры, а из второй извлекаться предыдущий, после окончания записываемого кадра буферы меняются местами. Для хранения одного кадра требуется 640*480*16 = 4.915*10^6 бит, что гораздо больше имеющейся на борту Cyclone II памяти on-chip. Поэтому будем использовать для хранения кадров память SDRAM, расположенную отдельным чипом на плате DE-1. Это позволит нам организовать фрейм буфер для решения технической задачи и даст возможность потренироваться в написании контроллера SDRAM.

Следующая проблема вытекает из решения предыдущей. При использовании памяти SDRAM в нашем проекте необходимо учитывать два важных момента: во-первых, работает память на высокой для нашего дизайна частоте 120 МГц и перед нами появляется новая проблема — передача данных из клокового домена камеры в клоковый домен SDRAM; во-вторых, для достижения максимального быстродействия писать в SDRAM следует целыми векторами данных, которые называются burst. Для решения этих проблем наилучшим способом подходит FIFO, организованное в on-chip памяти FPGA. Основная идея такова: камера на низкой частоте заполняет FIFO, после чего контроллер SDRAM считывает данные на высокой частоте и сразу одним вектором записывает их в память.

Вывод данных на монитор организован то такому же принципу. Данные из SDRAM записываются в FIFO, а затем извлекаются на частоте 25 МГц для подачи на ЦАП. После опустошения FIFO операция повторяется.

Самой мелкой проблемой является то, что настройки камеры «из коробки» нас не устраивают, и необходимо их изменить. Самый важный момент, камера выдает данные в формате YUV422, и необходимо поменять его на RGB444. Для обращения к внутренним регистрам OV7670 необходимо будет описать модуль передатчика I2C.

Теперь можно сказать, какие модули нам придётся реализовать, и какие задачи они будут решать.

• cam_wrp – модуль принимает данные с камеры и записывает их во входное FIFO;
• hvsync – модуль вырабатывает стробы для VGA, принимает данные из SDRAM, записывает их во входное FIFO и по стробу подает на ЦАП;
• sdram_cntr – контроллер SDRAM;
• FSM_global – автомат управления;
• camera_configure – модуль конфигурации и управления камерой.

На рисунке 3 приведена функциональная схема дизайна.

Рис.3

Рассмотрим подробнее каждый из модулей.

Модуль cam_wrp

Один из самых простых модулей. Его задача в момент действия строба hsync камеры принимать последовательно по два байта, формировать из них одно двухбайтовое слово и записывать его в FIFO. По сигналу от SDRAM контроллера передать ему все содержимое FIFO.

Для «упаковки» 2-х последовательных байт в одно слово используем сигнал wr_fifo, который инвертируем по клоку (делим частоту на 2). Когда этот сигнал в логической 1, записываем данные в младший байт, когда в логическом 0 — в старший. Также используем wr_fifo, как сигнал записи в FIFO. Кроме шины данных из FIFO выведена шина, на которую выставляется число записанных в него данных. Эта шина подключена к автомату управления. На рисунке 4 представлена временная диаграмма «упаковки» байт в двухбайтовые слова.

Рис.4

Модуль FSM_global

Модуль имеет весьма пафосное название, на деле это несложный автомат всего на 4 состояния, но выполняет он очень важную функцию. Отслеживая сигнал готовности sd_ready SDRAM контроллера, наполненность входного и выходного FIFO, автомат выдает в команды SDRAM контроллеру забрать данные из входного или записать в выходное FIFO. Чтение и запись происходят несколько раньше, чем FIFO полностью заполнится или опустошится. Главное, чтобы операции с FIFO на высокой частоте не закончились раньше, чем на низкой, — это гарантированно приведет к ошибкам. В части, посвященной SDRAM контроллеру, я приведу рисунок, иллюстрирующий эту особенность.

Модуль SDRAM_contr

Контроллеров SDRAM написано уже много, изобретать велосипед в очередной раз не хотелось, поэтому я решил изобрести велосипед на гусеничном ходу. А именно, SDRAM контроллер, заточенный под этот конкретный проект. Это упростит управление и чуть-чуть ускорит работу. Граф переходов автомата для полноценного SDRAM контроллера представлен на рисунке 5.

Рис.5

Подумаем, что мы сможем из него исключить.

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

Во-вторых, так как мы всегда будем записывать и считывать данные вектором длиной 640, можно отказаться от возможности работы с отдельными числами, будем писать только burst.

В-третьих, не надо думать над адресом, мы просто будем инкрементировать его после каждого burst и обнулять в конце каждого кадра. Получившийся граф переходов представлен на рисунке 6.

Рис.6

Стартует контроллер в состоянии idle. Перед началом нормальной работы необходимо провести инициализацию микросхемы памяти (состояние автомата s0_MRS), после чего выставляется флаг mode_flag, контроллер переходит в состояние ожидания, и мы можем записывать и считывать данные. Для этого из модуля fsm_global поступает команда начала чтения или записи, открываем необходимый столбец в выбранном банке (состояние s0_ACT), и далее должно происходить чтение или запись (состояния s0_WRIT, s0_READ). К сожалению, обойтись одним burst не выйдет, глубина столбца в нашем чипе памяти всего 256 16-ти битных слов, а нам необходимо записывать вектор длиной 640. Придется писать за 3 burst, два по 256 и одни на 128. Видно, что половина третьей строки остается пустой, то есть мы нерационально используем ресурсы, но так как недостатка в них у нас нет, я решил не усложнять автомат и смириться с этим.

Что касается адресов, для них выделены разные регистры для чтения и записи, которые инкрементируются перед каждым bust. Таким образом, для записи вектора длиной 640 мы проходим 640*4=1440 адресов. Стробом вертикальной синхронизации камеры или VGA адреса обнуляются для записи и чтения соответственно.

Мы используем двойную буферизацию: в один буфер пишем из другого читаем. Для упрощения один буфер я разместил в банке 0, а второй в банке 1 чипа SDRAM. Банки для чтения и записи меняются местами после окончания приема кадра с камеры. На рисунке 7 представлены временные диаграммы записи одного вектора. Видно, что запись разбита на 3 части: после каждой адрес инкрементируется, вся передача происходит под стробом cur_wr. Для чтения диаграмма аналогична.

Рис.7

На рисунке 8 показано, как происходит запись в SDRAM данных с камеры в сравнении со временем заполнения FIFO. Обратите внимание, что мы начинаем писать в SDRAM, не дожидаясь окончательного заполнения FIFO.

Рис.8

Модуль hvsync

Это один из двух модулей в этом проекте, написанных не мной. Однажды я уже реализовывал похожий модуль, повторяться мне было неинтересно, поэтому я использовал отличный модуль, написанный авторами сайта marsohod.org. В этом модуле нет ничего лишнего, он параметризован и легко может быть настроен для любого разрешения экрана. Я практически не изменял его, добавил только FIFO, подключенное к SDRAM контроллеру, и сигналы обвязки для него. С FIFO выведена шина, на которую выставляется количество записанных в него данных, эта шина подключена к автомату управления по аналогии с входным FIFO. Выход FIFO подключен к wire, которые идут на ЦАП.

Модуль camera_configure

Изначально позволив себе вольность домашнего проекта и невнимательно прочитав документацию, я хотел запустить камеру с настройками «по умолчанию», но оказалось, что без настройки OV7670 передает информацию в формате не RGB565, а в YUV422. Переписывать ничего не хотелось, и я решил, что надо делать все по уму и нормально проинициализировать камеру. Так как камера управляется по I2C, в голову пришла идея использовать NIOS. NIOS с коркой I2C с opencore завести с полпинка не удалось, но я случайно наткнулся на Verilogовский модуль инициализации именно для OV7670. Он так легко встроился в код, что не пришлось практически ничего менять, изменил только одну строку: вместо RGB565 активировал режим RGB444, так-как на плате стоят именно 4 разрядные АЦП. На рисунке 9 представлена временная диаграмма программного сброса камеры записью числа 0х80 по адресу 0х12.

Рис.9

Демонстрация результата

После того, как все модули написаны, соединяем их вместе в топ-модуле, собираем в Quartus, и можно тестировать. Видео демонстрирует полученный результат.

Мной было выбрано не очень удачное время для съемки — закат и очень яркое солнце, — камера неадекватно реагирует на слишком яркие солнечные блики. Видно, что движущиеся объекты отображаются корректно, дерганий и шлейфов нет. Именно этого я и добивался, используя FPGA, которая позволяет обрабатывать все 30 (а возможности камеры больше) fps малой кровью. Если говорить о четкости изображения, то могу сказать, что текст с листа А4 читается без сложностей, к сожалению, фото с монитора получаются хуже, чем в реальности. На рисунке 10 показан фрагмент листа А4 с документацией на камеру.

"

На представленных видео и фото видны некоторые недостатки: первый с резкостью и второй с цветом.
Проблему с резкостью на видео я связываю с неидеально выставленным фокусом. Фокус настраивается на камере механически, вкручиванием или выкручиванием находящейся на резьбе линзы. Резьба пластиковая и имеет довольно большой люфт, даже от небольшой тряски резкость может ухудшаться.

Проблема с чрезмерной зеленожелтостью белого листа, мне кажется, связана с проблемой с балансом белого: съемка производилась в помещении с освещением, далеким от естественного. Также на ситуацию с цветностью могут влиять настройки камеры. Я практически не экспериментировал сними, использовал как magic number.

Заключение

Поставленная задача — вывод изображения с камеры OV7670 на VGA монитор в реальном времени, — решена. Если сравнить результат, полученный в данном проекте с результатом, полученным другими разработчиками, использующими микроконтроллеры или Arduino, видно, что они уступают в скорости отображения движущихся объектов. По трудоёмкости данный проект не превосходит аналогичные, выполненные с использованием микроконтроллера. Человек, обладающий начальными знаниями в разработке дизайна FPGA, может реализовать его за несколько дней. Проект имеет большой потенциал к расширению, возможна фильтрация полученного изображения, распознавание предметов и прочее. Дизайн на чипе Cyclone II занимает следующие ресурсы: LE – 745(4%), memory bits – 32768 (14%), PLL – 1 (25%), Embedded Multiplier — 0(0%), — таким образом, разработчикам остается еще достаточно ресурсов для реализации своих идей.

Послесловие

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

Выражаю благодарность ishevchuk за советы по содержанию и оформлению статьи и моей девушке за проверку орфографии.

Скачать архив с исходниками можно тут (Я.Диск).

Автор: shvlad

Источник