OV7670 + ATmega48 + uDisp320240 = ? Часть 1.

В начале было слово  🙂 я подумал опубликовать наработки сразу по законченному проекту — т.е. в статье описать конструкцию, привести исходник, схему и прочую лабуду. Однако процесс освоения видеокамеры OV7670, дисплея uDisp320240 и вообще вывода видео оказался настолько тернистым увлекательным, что одной статьёй здесь не обойтись. Поэтому некоторые моменты своего пути в этом направлении я освещу серией статей. Расскажу и покажу проблемы, с которыми встретился, и результаты, которых достиг. На подобный анализ меня побудило практически полное отсутствие информации в интернете по указанному вопросу, в том числе и на зарубежных сайтах. Есть пара размазанных примеров, но с применением ARM-ов, FIFO и прочей лабуды. Однако берусь утверждать что и без них (ARM, FIFO) возможно обойтись в нелёгком деле вывода видео на цветной экранчик. Кроме того встречал в интернете мнения насчёт того, что лучше — опубликовать готовую наработку позже, или «сырую» побыстрей. Оные были однозначны — лучше сразу, пусть и «сырую», а народ скопом допилит гораздо быстрее и плодотворней. С такими мыслями начнём.
Ну, так, для затравки, сразу сообщу, что решение вопроса по 2-му способу подключения (напрямую камера на микроконтроллер AVR) не получилось… Я пробовал выполнить все действия для передачи изображения на камеру в чёткой последовательности с алгоритмом, только гораздо медленнее — чтобы 48-я успевала отработать все сигналы. Думал, что картинка очень медленно, но всё-таки будет вылазить на экран — фигушки. В какой-то момент времени камера вообще начинает гнать пургу, наверное из-за срыва внутренних процессов, т.к. её тактовый сигнал имеет ограничения снизу 🙁 🙁 🙁 Ну и ладно! Значит сделаю по 3-му способу (использовав простую логику для быстрых процессов).

Проанализировав документацию на камеру и дисплей я пришёл к выводу, что для отображения лучше всего мне подходит режим 16 bit Generic + SPI. В этом режиме данные изображения заносятся в видеоОЗУ дисплея по RGB-интерфейсу, а управление дисплеем происходит по 3-х проводному SPI. Напомню, что режимы работы uDisp320240 выбираются перемычками PS3-PS0 (smd 0604 резисторы 0 Ом),  расположенными на стороне платы дисплея обратной от экрана. Однако там меня ждала первая засада. Производители (чтоб им хорошо было 🙂 ) в таблице расшифровки режимов работ подписали перемычки начиная с младшего разряда — PS0,PS1,PS2,PS3, т.е. так, как они физически расположены на плате. А вот кодировку режимов нанесли так, если бы в таблице разряды PS следовали по старшинству, т.е.  так —  PS3,PS2,PS1,PS0. Поэтому кодировка получилась зеркальная по горизонтали — учитывайте это, коллеги.
Функциональная схема нарисовалась у меня в голове почти сразу. Т.к. на шину данных дисплея нужно подавать 16-ти битное слово DB[17;0] (DB9, DB0 — не используются), а камера гонит 8-ми битное (D[7;0]), то регистр-защёлка для хранения полуслова напрашивался сам собой, вот в таком включении:
Сигналы синхронизации: — VSYNC идёт напрямую с камеры на дисплей; — из HREF и PCLK делаем строб защёлки Latch Enable старших разрядов данных LE и тактовый сигнал точек (пикселей) DotCLocK — DCLK:
Ниже приведены осциллограммы работы моей получившейся схемы.
Просю пардону за параличные, под линейку нарисованные, изображения. На бумаге они смотрятся ничё так.
DD1 — 74HC08 (4 элемента 2�?), DD2 — 74HC74 (2 D-триггера). Чтобы получить счётный Т-триггер, D -триггер нужно включить так:DD4 — 74HC573 (8-ми разрядный регистр-защёлка).
Пара фраз о работе схемы. Непрерывно следующие PCLK с камеры бланкируются на элементе «�?» строчным синхросигналом HREF (тоже с камеры). Т.е. PCLK проходят на счётный вход Т-триггера в моменты времени, когда HREF активный (в нашем случае в лог. «1»). Триггер делит PCLK  на два. С выходов Q и Q_инверсный, элементами»�?» выделяются сигналы LE (по ним защёлкивается старшая часть полуслова данных), и синхросигналы DCLK (по ним дисплей считывает 16-ти разрядное слово данных цвета точки/пикселя — с камеры младшие 8 бит, а с регистра «защёлкнутые» ранее импульсом LE старшие 8 бит).
Я думаю, что работа схемы понятна и без моих косноязычных пояснений — их я так написал, для проформы 🙂
Ну, решил проверить рождённую схему. На беспаечной макетке, купленной на всё том же Деалэкстриме за копейки, была собрана указанная выше схема. �? вот, блин, какие очередные грабли были пойманы… На частоте десятков килогерц она работала, как ей и предписано. А вот когда я вдул 24 МГц получилась такая бяка.
Н-да… Нужно было учесть, что логические элементы и триггера имеют задержку. �? теперь эту задержку нужно уже было вносить искусственно, чтобы «подвинуть» импульсы  Т вправо относительно выходных с триггера. Что и было сделано с помощью 4-х элементов «НЕ».
DD5 — 74HC04 (6 элементов «НЕ»). Сначала я подключил два инвертора, но их сдвига оказалось недостаточно.
Ну, для видеоинтерфейса всё, вроде готово. Пришло время задуматься об управлении камерой и дисплеем. �?нтерфейс управления видеокамерой OV7670 с громким названием SCCB — это не что иное, как старый добрый I2C, поверьте мне, друзья. �?нтерфейс же управления дисплеем uDisp320240 (контроллер SSD2119) в рассматриваемом случае 3-х проводный 9-ти битный SPI — такие мы программно реализовывали уже не один десяток раз, да хоть 24-х битный. Поэтому в отношении реализации управления, что камерой, что дисплеем, на аппаратном, подчёркиваю, аппаратном уровне, проблем абсолютно не вылезло. А вот на логическом 🙁 …………………………………………………………………………………………………………………….
Для первой статьи как бы хватит, господа. Ждём следующей и очень скоро!