Для реализации устройства была разработана печатная плата, в которой, правда, оказалось достаточно много перемычек. Забегая вперёд, скажу, что пока как минимум одна перемычка пригодились для корректировки схемы в процессе освоения. Разъём программирования тоже отдельно не выведен по причине, что разводчик плат из меня, не особо опытный, а перекрёстных линий оказалась куча. На плату uDisp320240 дополнительно впаивается двухрядная гребёнка штыревых контактов. Ну и на ней же задаются режимы работы интерфейсов: видео (16 битный RGB) и управления (3-х проводной SPI).
На фото я обозначил соответствие перемычек таблице их состояний для указанного выше режима 16BIT GENERIC+SPI.
Разъём-мама 2х9 для видеокамеры OV7670 использован обычный для запайки в отверстия, но я подогнул ему ноги в стороны параллельно ПП и припаял со стороны печати как планарный. Так я хотел сделать, чтобы вся конструкция в сборе внешне напоминала фотоаппарат, но в голове два раза отзеркалил разъём для OV7670 и, в итоге, объектив «фотоаппарата» смотрит не из центра корпуса, а сверху него 🙂 Вот так:
Но даже и то положение, которое я планировал изначально, было неправильно, господа! Камеру нужно располагать с поворотом на 90 градусов против ЧС, если смотреть на фото выше — так как ориентирована надпись «OV7670» на камере, БЛ?Н, какой же я плуг!!! Товарисчи! Разводите плату с учётом моих ошибок!
В программной части я использовал куски кода с прошлых проектов и проверки камеры по I2C. 3-х проводный 9-ти битный SPI реализовал программно. Посмотрите исходник. Он в архиве вместе с печатной платой устройства. По временным характеристикам исходил из максимальной частоты DCLK дисплея, которая согласно даташита SSD2119 Table 13-4 стр. 74 не может быть больше 8,2 МГц. Камера OV7670 же нам даёт при 30 кадрах в секунду частоту DCLK равную 24 МГц. Ограничимся 15-ю кадрами в секунду, при этом частота DCLK будет равна 12 МГц на выходе с OV7670, и 6 МГц после делителя на триггере DD2 — т.е. в пределы влазим. Контроллер ATmega48 работает на частоте 20 МГц от внешнего кварца (это всегда можно посмотреть в mikefile).
?так, макет собран… Включаю… Не работает. Серый с разводами экран, нет ни намёка на какую-то видеоинформацию. ?зменения настроек ни к чему не приводили. Я понимал, что вряд ли сразу увижу нормальную картину, но ожидал хоть каких-нибудь изменений экрана дисплея в зависимости от того, что «видит» сейчас перед собой видеокамера. В частности, при направлении её на лампу, должно было быть хоть какое-то пятно, и не обязательно светлое.
……………………………………………………………
Пляски с бубном и прочие действа…
…………………………………………………………..
Порывшись в даташите дисплея в стопицотый раз я выяснил, БЛ?Н, что для RGB режима необходимо постоянное присутствие тактовых импульсов пикселей DCLK — в данном режиме они являются синхроимпульсами и должны присутствовать на этом выводе (DCLK) даже в периоды неотображения (даташит SSD2119 Table 6-2 стр. 27 и Note для Table 13-4 стр. 74). Я же элементом «?» DD1.1 (см. Часть 1.) бланкировал импульсы DCLK импульсом HREF — перехитрил сам себя. ?з положения вышел впаяв перемычку с Uпит (т.е. «повесив» постоянную лог. 1) на верхний по схеме вход DD1.1. На фото печатной платы это хорошо видно (верхняя левая перемычка).
Также маленько плуганул с подключением индикаторного светодиода: запамятовал, что оные подключены к питанию, а не к «земле». Пришлось паять «соплю» (вверху справа по фото).
После коррекции схемы я увидел на экране меняющиеся в зависимости от положения объектива пятна , т.е. было понятно, что камера что-то таки выдаёт, а дисплей это «что-то » отображает. Подкрутил линзу резкости и … о чудо — на экранчике явно увидел круги ГГ сабвуфера компьютерной АС. ?зображение было немного обрезано и с неестественными цветами.
……………………………………………………………
Пляски с бубном и прочие действа…
…………………………………………………………..
Ну и итоговое видео. Без него все мои потуги здесь бессмыслены и не представляют никакого интереса для тру-эмбеддеров. Смотрим:
Видео, конечно, паршивого качества — оператор я ещё тот 🙂 да и освещение выбирать не умею правильно, поэтому постоянные блики. Да и снимать, когда в одной руке камера, снимающая камеру, которая находится в другой руке, глядя одним глазом на одну, а другим на другую камеру…. Но, поверьте на слово, картинка на uDisp320240 достаточно чёткая, цвета естественные. Основные недоработки:
1. Нет синхронизации по кадрам. Хорошо видно, что при движении камеры слева направо картинка «останавливается», в моменты, когда скорость перемещения камеры совпадает со скоростью движения несинхронизированных кадров на экране. ? наоборот:при перемещении справа налево кадры по экрану «бегут» быстрее.
2. Неправильное ориентирование камеры относительно экрана дисплея, о чём я упоминал выше. Если бы ещё камера была повёрнута на 180 градусов, то настройками можно было бы картинку правильно сориентировать (задать обратную адресацию сканирования), а так получилось то что есть 🙁 .
При всех существующих недоработках, коллеги, я выяснил главное: связка логики с простеньким распространённым микроконтроллером вполне работает!!! А остальное — дело времени, чтобы разобраться во всех настройках и камеры, и дисплея
Не буду утомлять вас описанием той многочасовой рутины, как я менял разряды в управляющих регистрах дисплея и камеры, экспериментируя и спотыкаясь, втыкая щупы осциллографа чуть ли не в каждый вывод, пытаясь для начала хотя бы засинхронизироваться по кадрам. ? синхроимпульсы на месте, и настройки вроде в порядке, а результата пока нема 🙁 Настроек, конечно куча! ? одновременных настроек для камеры и дисплея! Да ещё и даташит на камеру написан о-о-чень неподробно.
Код инициализации и настройки камеры утащен мною из каких-то закромов интернета, даже не помню из каких. Когда будете смотреть исходник обратите внимание, что там три последовательности команд для OV7670. Первая — это то, что я сам пробовал писАть, вторая и третья — из этих ваших интернетов. Первая последовательность работает, но изображение как в негативе, цвета неестественные. Вторая последовательность даёт очень естественные цвета, третья — более яркие. Кроме того, изображение ещё зависит и от напряжения питания. Скажу вам 3,6 В и 3,9 В меняют картинку существенно. Вывод делаю такой — я на правильном пути! Ура! По крайней мере основная цель достигнута. Но вот с настройками, что камеры, что дисплея волей-неволей придётся разбираться досконально — с кондачка не прокатит. Помогайте мне, друзья!
P.S. Пожалуйста, перечитайте ещё раз и вместе с первой частью, а то я тут понаписывал не статью, а неупорядоченный набор эмоций !
Здравствуйте.
Может вы этим сталкивались, какие регистры нужно отправить через I2C на камеру OV7670 для того, чтобы перевести камеру в режим RGB565.
com7 (0x12), com15 (0x40) Но не всё так просто ((( Есть ещё куча взаимосвязанных и переплетённых настроек с которыми до конца не разобрался.
Спасибо.
Буду пробовать…
А Вы на каком стенде пробуете запустить камеру?
Я делаю немного по-другому (работаю с Bascom-AVR).
Пробую прогнать данные с камеры OV7670 через Atmega128A-AU после на TFT 2.4″ LCD ILI9325. Для начала внешний кварц на 16МГц. Такт через Timer1 на камеру 8МГц с камеры 4 МГц.
Задавал вопрос, потому что есть подозрения, что с камеры идёт не RGB565, а другой режим.
Я так пробовал. Ни хрена не выйдет, коллега ((( Не «пережуёт» и, тем более, не «выплюнет» Мега столько информации.
Тут в самом конце есть надпись «Внимание: эта модель камеры не имеет встроенного FIFO. Частота вывода данных составляет 24 Мбайта в секунду, поэтому для обработки может потребоваться контроллер класса ARM»
получается делать нужно так же как у вас (через триггеры)…
Коллега! Вы пытаетесь заюзать камеру по 2-му способу, который я описал в статье. Я же делаю сейчас по 3-му способу. Некоторые успехи есть (описаны выше), но документация на камеру очень краткая и специфичная. К тому же в интернете мало сведений по опыту использования этой камеры, а те что имеются — нередко противоречивы. Основную проблему для меня сейчас составляет именно взаимозависимость и перекрёстность настроек камеры. Да и с работой дисплея в таком режиме тоже не всё понятно. Давайте объединять усилия )))
Сейчас думаю докупить FIFO AL422B тут. Про AL422B пишут, что нужен для быстрой записи и медленного считывания МК.
Здравствуйте.
?нтересные и познавательные у Вас статьи про видеокамеру OV7670. Весь интернет перерыл — ничего лучше ваших статей не нашел. Вот заказал такую камеру на aliexpress, скоро уже должна прийти. Я сам вообще новичок в обработке изображений, но вот настала такая потребность.
Спасибо большое !!! К сожалению сейчас в силу некоторых обстоятельств разработки несколько притормозились ((( Но найду время — результаты обязательно выложу!
Уважаемый s_black!
Синхронизацию по кадрам следует связать с сигналом VSYNC, например, после заднего фронта этого сигнала, картинка каждый раз начинает выводится на дисплей с одного и того же места.
Таким образом, VSYNC будет служить «кадровым» синхроимпульсом.
Каково Ваше мнение по этому поводу?
Я так и делаю. Но синхронизации нет ((( Наверное упускаю какую-то настройку в дисплее.
Очень бы хотелось узнать у Valera, его эксперименты с камерой продолжаются и есть ли какой — то успех в этом направлении?
Для forter
Микросхему FIFO AL422B прислали. На днях вытравлю плату для AL422B и попробую связать всё вместе.
Здравствуйте, s_black!
На 74 странице ДШ на контроллер дисплея указана отрицательная полярность сигналов VSYNC. Камера, насколько я понимаю, выдает этот сигнал положительной полярности (2 младших бита регистра 0х15, похоже, равны нулю по умолчанию). Может быть с этими настойками попробовать?
Очень похоже, что синхронизируется дисплей не по тому фронту…
Доброй ночи, господа.
Заранее прошу меня извинить, если посчитаете, что обратился не по адресу. Но также прошу оказать мне посильную помощь)
Делаю у себя «умную» квартиру на базе Arduino. С программизмом, и тем более с AVR не знаком; но по кускам кода из инета уже создал рабочую систему на Mega2560 + DHT11s + raindrops + IR-датчики + «релешки-клапаны». Также в мои планы входило использование камеры данного топика (OV7670 без буфера) для контроля лестничной площадки подъезда: включение камеры и LCD-экрана по IR-датчику или по нажатию на кнопку звонка и запись фото (не видео!) гостя на SD-карту (возможно: серия фоток с минимальным интервалом). Камеру купил давно, LCD (TFT_320QVT без шилда) приехал на днях, также продал Mega2560 , а себе прикупил Arduino Due, т.к. уже начитался об ограниченных возможностях Mega по работе с данной камерой.
После 3 дней копания инета, так и не нашел рабочего примера соединения камеры с экраном; экрана без шилда с Due; и камеры с экраном и с Due.
Help me, please!
To forter:
Пробовал. Менял в различных вариациях (((
To Scaoo:
Так мы тут все и занимаемся данной проблемой. Если бы всё было так просто — то интернет был бы просто забит рабочими примерами.
Подключайтесь к нам!
Для Scaoo
Для «умной» квартиры, можно использовать фото глазок
вот пример. Она фотографирует и сохраняет на карту памяти.
Дополнительно: к системе Arduino можно добавить SIM900 и связать кнопку звонка у фото глазка, т.е. при нажатии на кнопку звонка будет отправляться сообщение на Ваш телефон с информацией.
Для Scaoo
Немного не точно написал. Указанная модель фото глазка (ссылка выше) не может сохранять на карту памяти. Вот эта сохраняет данные на карту памяти.
To Valera:
Зачем мне этот глазок (который вдобавок и выглядит снаружи как камера), когда у меня есть микроконтроллер)
Вот только с заменой Меги2560 на Due начали вылазить еще проблемки: новый МК 3-х вольтовый — датчики системы поборол, а все добро, что сидит на I2C (таймер, lcd1602) — не могу! Может кто сталкивался с аналогичной проблемой?
Согласен с Scaoo — самому гораздо интереснее сделать, к тому же функционал можно потом усовершенствовать. Меги 2560 хватит за глаза, если пойти по пути указанному выше в статье. Удачи!
Я имел ввиду использовать видеоглазок именно для записи на SD карту, а управляться будет через МК.
С камерой разобраться возможно (и будет работать), но записывать видео или фото с камеры на карту не удастца, из-за не знания принципа кодировки .jpg и .avi
To s_black!
Коллега, а как Вы обрабатываете бит проверки правильности передачи байта!
Как я понял, это девятый бит, его должна формировать камера.
Он, при правильной передаче равен 1 или 0?
Можно чуть подробнее ответить?
Я не понял Вашего вопроса. коллега. С камерой — обычный I2C. С дисплеем — 9-ти битный SPI. 9-й бит там для определения того, что передаётся (команда/данные).
Доброй ночи, господа.
Похвастаюсь своими «успехами»: Due и экран TFT_320QVT подружил; тач и ридер — тоже. Также нечаянно проверил работу экрана при 5В на входе питания и подсветки — несмертельно, но неработоспособно))
Теперь прошу или автора данной статьи, либо кого-то из комментаторов нарисовать мне принципиалку для соединения OV7670 со всем этим моим добром. Код буду пытаться создать сам.
P.S. Добра типа 155ЛЕ,Л?,ЛН имею около килограмма; макетки китайские уже купил, клеить-паять умею.
Здравствуйте, коллеги!
Наконец — то и у меня что — то появилось на дисплее. Но вот незадача — картинка очень зашумлена и никак не могу это побороть. Отдельно на фото:
1. Экран дисплея при закрытом объективе камеры.
2. Камера направлена на телефонный аппарат.
По ссылке можно посмотреть фотографии (не ругайте за их качество). Может быть, у кого — то были подобные проблемы и они уже решены? Прошу помощи.
Здравствуйте. Скажите, пожалуйста. Получится ли по второму способу получить один кадр и перегнать его на комп?
А то через неделю ожидаю такую камеру и уже жалею, что не взял ttl jpeg.
Максим!
Задача передачи кадра на компьютер мною не ставилась.
Я просто пытался вывести изображение на TFT — дисплей.
Пока естественных красок так и не получилось.
Естественных красок не получилось, т.к. Вы не использовали «волшебную» последовательность инициализации, о которой я упоминал.
Один кадр снять и перегнать в комп — никакой проблемы нет!
s_black!
О какой последовательности речь?
Я использовал много разных, но результат один — краски неестественные.
Просто, как мне кажется экран шумит.
Все — таки, по поводу последовательности, чуть подробнее, пожалуйста.
Цитата: » Код инициализации и настройки камеры утащен мною из каких-то закромов интернета, даже не помню из каких. Когда будете смотреть исходник обратите внимание, что там три последовательности команд для OV7670. Первая — это то, что я сам пробовал писАть, вторая и третья — из этих ваших интернетов. Первая последовательность работает, но изображение как в негативе, цвета неестественные. Вторая последовательность даёт очень естественные цвета, третья — более яркие. «
Спасибо за отзывчивость. Еще вопрос- какой лучше приобрести кварц для камеры? Подключать буду к ардуино мега.
А зачем кварц для камеры?
На вход XCLK камеры нужно подать тактовый сигнал 10-48 МГц. С ардуины его, вроде, не взять. Соответственно нужен генератор. ?ли я чего не понял? Спасибо.
Я бы не советовал Вам рассматривать ардуину как «ардуину» — уж извините за каламбур ))) ?сползуйте её как макетную плату и работайте с контроллером напрямую без привязки к «ардуинскому» языку ВУ. Таким образом сможете выдать тактовый сигнал на камеру с любой нужной ноги контроллера.
Смысл уловил, спасибо. Буду вникать. Надеюсь на помощь в практических вопросах в будущем.
Ардуину DUE можно рассматривать до 320*240*8bit (только для снимка).
Хочу на ней организовать поиск метки
С 6-ой ноги ардуины подаю на камеру 42Mhz так:
analogWrite(6, 128);
PWMC_ConfigureChannel (PWM, 7, 0, 0, 0) ;
PWMC_SetPeriod (PWM, 7, 2);
PWMC_SetDutyCycle (PWM, 7, 1) ;
мне нужен только Y канал, сохраняю его в двумерный массив прямо в проц.
потом разбираю картинку.
У меня вопрос по OV7670:
можно ли запрограммировать камеру чтобы она слала PCLK только для Y канала?
Алексей, преследую подобную цель. Если возможно, скиньте скетч или наработки на мыло mach3_86@bk.ru
Буду примного благодарен.
вот так забираю картинку
byte pict [max_y][max_x];
void get_pict() {
while ((g_APinDescription[vsync_pin].pPort -> PIO_PDSR & g_APinDescription[vsync_pin].ulPin) == 0) {};
while ((g_APinDescription[vsync_pin].pPort -> PIO_PDSR & g_APinDescription[vsync_pin].ulPin) != 0) {};
for (y = 0; y PIO_PDSR & g_APinDescription[href_pin].ulPin) == 0) {};
while ((g_APinDescription[href_pin].pPort -> PIO_PDSR & g_APinDescription[href_pin].ulPin) != 0) {
while ((g_APinDescription[pclk_pin].pPort -> PIO_PDSR & g_APinDescription[pclk_pin].ulPin) == 0) {};
pict[y][x++] = REG_PIOC_PDSR >> 1;
while ((g_APinDescription[pclk_pin].pPort -> PIO_PDSR & g_APinDescription[pclk_pin].ulPin) != 0) {};
while ((g_APinDescription[pclk_pin].pPort -> PIO_PDSR & g_APinDescription[pclk_pin].ulPin) == 0) {};
while ((g_APinDescription[pclk_pin].pPort -> PIO_PDSR & g_APinDescription[pclk_pin].ulPin) != 0) {};
}
}
}
D0-D7 подключаю на ноги 33-40
…можно ли запрограммировать камеру чтобы она слала PCLK только для Y канала?…
Что такое Y — канал? Мне кажется Вы не совсем правильно понимаете принципы кодировки цвета. Тактовые импульсы для пикселей PCLK одинаковы по сути что для RGB, что для YCbCr — форматов. Разница в формировании самих непосредственно пикселей. Успехов, коллега!
камера шлет слово (по 2 байта на пиксель). каждый байт разделен PCLK-ом.
для YCbCr это (Y0, Cb0), (Y1, Cr0), (Y2, Cb2), (Y3, Cr2) и т.д.
вот и получается что каждый второй байт — это канал Y каждого пикселя (оттенки серого цвета) в моем случае мне не нужны каналы Cb и Cr.
можно-ли заставить камеру настройками дергать PCLK-ом только каждый 2-ой байт?
Ну, так это как бы не отдельный канал…
Выделить нужный Вам клок можно простой логикой — это первое что приходит в голову. Хотя если внимательно пересмотреть настройки в камере (их там очень много) может быть и можно как-то это дело организовать.
Вот и «ахаюсь».
Нет у кого описания настроек камеры на русском?
Думаю, что нет ((( Пока сам не разберёшься (это я про себя) вряд ли найдёшь информацию. Так что словарь в руки и вперёд… )))