- PVSM.RU - https://www.pvsm.ru -
Прочитав много увлекательных статей об интересных разработках под FPGA, таких как тетрис [1], радиопередатчик [2] и другие [3], я тоже загорелся идеей сделать что-нибудь для души. Для этой цели мной была приобретена камера OV7670 [4] и отладочная плата DE-1 [5] фирмы 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 можно посмотреть здесь [6].
Становится ясно, что частота поступления данных с камеры и частота вывода данных на монитор отличаются, что исключает возможность прямого подключения. Выход из этой ситуации — использование кадрового буфера [7]. Выделим в памяти две равные области: в одну будет записываться текущий кадр с камеры, а из второй извлекаться предыдущий, после окончания записываемого кадра буферы меняются местами. Для хранения одного кадра требуется 640*480*16 = 4.915*10^6 бит, что гораздо больше имеющейся на борту Cyclone II памяти on-chip. Поэтому будем использовать для хранения кадров память SDRAM [8], расположенную отдельным чипом на плате DE-1. Это позволит нам организовать фрейм буфер для решения технической задачи и даст возможность потренироваться в написании контроллера SDRAM.
Следующая проблема вытекает из решения предыдущей. При использовании памяти SDRAM в нашем проекте необходимо учитывать два важных момента: во-первых, работает память на высокой для нашего дизайна частоте 120 МГц и перед нами появляется новая проблема — передача данных из клокового домена камеры в клоковый домен SDRAM; во-вторых, для достижения максимального быстродействия писать в SDRAM следует целыми векторами данных, которые называются burst. Для решения этих проблем наилучшим способом подходит FIFO, организованное в on-chip памяти FPGA. Основная идея такова: камера на низкой частоте заполняет FIFO, после чего контроллер SDRAM считывает данные на высокой частоте и сразу одним вектором записывает их в память.
Вывод данных на монитор организован то такому же принципу. Данные из SDRAM записываются в FIFO, а затем извлекаются на частоте 25 МГц для подачи на ЦАП. После опустошения FIFO операция повторяется.
Самой мелкой проблемой является то, что настройки камеры «из коробки» нас не устраивают, и необходимо их изменить. Самый важный момент, камера выдает данные в формате YUV422, и необходимо поменять его на RGB444. Для обращения к внутренним регистрам OV7670 необходимо будет описать модуль передатчика I2C.
Теперь можно сказать, какие модули нам придётся реализовать, и какие задачи они будут решать.
На рисунке 3 приведена функциональная схема дизайна.
Рис.3
Рассмотрим подробнее каждый из модулей.
Один из самых простых модулей. Его задача в момент действия строба hsync камеры принимать последовательно по два байта, формировать из них одно двухбайтовое слово и записывать его в FIFO. По сигналу от SDRAM контроллера передать ему все содержимое FIFO.
Для «упаковки» 2-х последовательных байт в одно слово используем сигнал wr_fifo, который инвертируем по клоку (делим частоту на 2). Когда этот сигнал в логической 1, записываем данные в младший байт, когда в логическом 0 — в старший. Также используем wr_fifo, как сигнал записи в FIFO. Кроме шины данных из FIFO выведена шина, на которую выставляется число записанных в него данных. Эта шина подключена к автомату управления. На рисунке 4 представлена временная диаграмма «упаковки» байт в двухбайтовые слова.
Рис.4
Модуль имеет весьма пафосное название, на деле это несложный автомат всего на 4 состояния, но выполняет он очень важную функцию. Отслеживая сигнал готовности sd_ready SDRAM контроллера, наполненность входного и выходного FIFO, автомат выдает в команды SDRAM контроллеру забрать данные из входного или записать в выходное FIFO. Чтение и запись происходят несколько раньше, чем FIFO полностью заполнится или опустошится. Главное, чтобы операции с FIFO на высокой частоте не закончились раньше, чем на низкой, — это гарантированно приведет к ошибкам. В части, посвященной SDRAM контроллеру, я приведу рисунок, иллюстрирующий эту особенность.
Контроллеров 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
Это один из двух модулей в этом проекте, написанных не мной. Однажды я уже реализовывал похожий модуль, повторяться мне было неинтересно, поэтому я использовал отличный модуль, написанный авторами сайта marsohod.org [9]. В этом модуле нет ничего лишнего, он параметризован и легко может быть настроен для любого разрешения экрана. Я практически не изменял его, добавил только FIFO, подключенное к SDRAM контроллеру, и сигналы обвязки для него. С FIFO выведена шина, на которую выставляется количество записанных в него данных, эта шина подключена к автомату управления по аналогии с входным FIFO. Выход FIFO подключен к wire, которые идут на ЦАП.
Изначально позволив себе вольность домашнего проекта и невнимательно прочитав документацию, я хотел запустить камеру с настройками «по умолчанию», но оказалось, что без настройки OV7670 передает информацию в формате не RGB565, а в YUV422. Переписывать ничего не хотелось, и я решил, что надо делать все по уму и нормально проинициализировать камеру. Так как камера управляется по I2C, в голову пришла идея использовать NIOS. NIOS с коркой I2C с opencore завести с полпинка не удалось, но я случайно наткнулся на Verilogовский модуль инициализаци [10]и именно для 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%), — таким образом, разработчикам остается еще достаточно ресурсов для реализации своих идей.
Что дальше? В дальнейшем я планирую расширять проект, добавив обработку изображения в реальном времени с использованием матричных фильтров [11].
Выражаю благодарность ishevchuk [12] за советы по содержанию и оформлению статьи и моей девушке за проверку орфографии.
" alt=«image»/>
При втором включении камера была неправильно проинициализированна, что привело к неожиданному селфи.
"
Скачать архив с исходниками можно тут (Я.Диск) [13].
Автор: shvlad
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/verilog/120539
Ссылки в тексте:
[1] тетрис: https://habrahabr.ru/post/247535/
[2] радиопередатчик: https://habrahabr.ru/post/178903/
[3] другие: https://habrahabr.ru/hub/fpga/
[4] OV7670: http://www.voti.nl/docs/OV7670.pdf
[5] DE-1: https://www.pvsm.ruftp://ftp.altera.com/up/pub/Altera_Material/Boards/DE1/DE1_User_Manual.pdf
[6] здесь: http://tinyvga.com/vga-timing
[7] кадрового буфера: https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D1%8B%D0%B9_%D0%B1%D1%83%D1%84%D0%B5%D1%80
[8] память SDRAM: http://www.datasheet4u.com/datasheet/A/2/V/A2V64S40CTP_ZentelElectronics.pdf.html
[9] marsohod.org: http://marsohod.org/
[10] модуль инициализаци: https://github.com/westonb/OV7670-Verilog
[11] матричных фильтров: https://habrahabr.ru/post/142818/
[12] ishevchuk: https://habrahabr.ru/users/ishevchuk/
[13] тут (Я.Диск): https://yadi.sk/d/p4Qv2TaprfoQ5
[14] Источник: https://habrahabr.ru/post/283488/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.