Don-stroitel.ru

Все о ремонте
6 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как подключить камеру к микроконтроллеру

Захват изображения с USB камеры при помощи STM32

image
Для собственного самообразования решил подключить USB камеру (вебкамеру) к STM32. У меня уже была отладочная плата на базе STM324F429, способная выводить изображение на VGA монитор, так что для проверки работы камеры я использовал именно ее.

Что выбрать: HAL или SPL?

Понятно, что USB-контроллер должен работать в режиме Host. До этого с USB Host я толком не работал, а в данном случае нужно было обязательно использовать режим Isochronous Transfers, для которого традиционно очень мало примеров. При этом для HAL STM32 Cube может генерировать код для USB Host Audio Class, так что в качестве основы я использовал именно сгенерированный пример. Этот пример предназначен для работы с USB аудиокартой.
Чтобы код драйвера USB начал выдавать отладочные сообщения, нужно установить константу:

После подключения аудиокарты микроконтроллер ее действительно обнаружил — драйвер USB и код аудиокласса выдали различные отладочные сообщения в окно вывода Semihosting, что означало, что железо работает нормально.
Дальше я занялся переделкой кода аудиокласса в класс UVC.

Стоит отметить, что большинство USB видеокамер работают с использованием специального USB-класса UVC (USB Video Class).
Ранее я уже сталкивался с ним.

Попробую кратко рассказать, что происходит у меня в программе.

1. Анализ дескрипторов

Первым делом нужно получить от камеры дескрипторы и проанализировать их.
Получением дескрипторов от камеры занимается драйвер USB от STM, так что пользователю остается лишь их анализ. При этом важно, чтобы значение «USBH_MAX_SIZE_CONFIGURATION» было достаточно большим (у меня оно равно 1024), иначе получаемые дескрипторы просто не уместятся в памяти контроллера.

При анализе дескрипторов нужно проверить, относится ли подключенное устройство к классу UVC.
Также в составе дескрипторов нас интересуют различные варианты настройки интерфейса, в частности — его номер и размер конечной точки (endpoint). Камера передает несколько вариантов размера конечных точек, которые она поддерживает, и нам нужно выбрать наиболее подходящий.

Допустимый размер конечной точки ограничивается аппаратным буфером FIFO контроллера. То, как этот FIFO будет распределен для использования под разные задачи USB, настраивается в файле «stm32f4xx_ll_usb.с» (искать по слову «GRXFSIZ»). К сожалению, необходимые константы там забиты прямо в коде, так что мне пришлось поправить этот файл, чтобы максимально увеличить область RX FIFO.

Кроме того, в дескрипторах передаются все возможные режимы передачи изображения камерой. Среди них можно выделить дескрипторы типа «Format Type Descriptor» — они описывают возможные форматы передачи изображения. Нас интересуют наиболее распространенные YUY2 (Uncompressed Format) и MJPEG (MJPEG Format). Также после каждого из таких дескрипторов идут несколько дескрипторов типа «Frame Type», каждый из которых соответствует определенному размеру изображения, передаваемого камерой.
Каждый из этих дескрипторов соответственно содержит поля «bFormatIndex» и «bFrameIndex», значения которых можно использовать для выбора режима работы камеры.

Таким образом, для пользователя задача анализа дескрипторов сводится к тому, чтобы найти нужные дескрипторы в массиве данных, полученном от камеры, и определить подходящие значения адреса конечной точки, по которой будут передаваться данные от камеры, номера интерфейса, bFormatIndex, bFrameIndex.

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

Здесь стоит заметить, что пример кода от STM выглядит очень путано. В нем вроде бы и сделана поддержка режимов OUT (передача данных от хоста) и IN (передача данных к хосту — нужный нам вариант), но в реальности режим IN реализован только частично. Зато разработчики напихали туда работу с HID (для регулировки громкости), и огромную кучу разнородного кода поместили в один единственный файл. Мне пришлось значительно переработать весь этот файл, к примеру, я выделил анализ дескрипторов и работу с принятыми данными в отдельные файлы.

Сам драйвер USB содержит в себе баг, нарушающий работу конечных точек Isochronous IN.

2. Настройка параметров камеры

Следующий этап — передать камере определенные параметры — в частности «bFormatIndex» и «bFrameIndex», для того, чтобы указать ей, какого размера и в каком режиме она должна передавать изображение.
В HAL этот процесс производится в функции USBH_UserProcess().
В протоколе имеются специальные запросы (Request) GET_CUR — запрос текущих настроек камеры и SET_CUR — установка новых параметров камеры. Каждый из этих запросов должен быть определенного типа — PROBE_CONTROL (пробная установка параметров) и COMMIT_CONTROL (подтверждающая установка параметров).
Таким образом, Host вначале отправляет определенные настройки камере (SET_CUR + PROBE_CONTROL), затем считывает их из камеры (GET_CUR + PROBE_CONTROL). Уже на этом этапе камера должна вернуть адекватные значения, включая те, что были установлены. После этого нужно подтвердить установку значений, отправив запрос (SET_CUR + COMMIT_CONTROL).

Читайте так же:
Базальтовый утеплитель производители в России
3. Запуск передачи данных

На этом этапе нужно отправить на камеру запрос «Set Interface». Он уже реализован в драйвере USB — в виде функции «USBH_SetInterface()». В качестве параметров в нее нужно передать значения «bInterfaceNumber» и «bAlternateSetting», полученные ранее во время анализа дескрипторов.
Получив этот запрос, камера начинает передачу данных на микроконтроллер-Host.

4. Обработка принимаемых данных

После того, как камера начинает предавать данные, задачей контроллера становится их обработка.
Пользовательский код должен не реже, чем в 1 мс проверять, не появились ли новые данные от камеры; и если они появились, обрабатывать их.
В HAL предполагается, что пользовательский код обработки данных должен вызываться из callback функции «BgndProcess», которая, в свою очередь вызывается из функции MX_USB_HOST_Process() — единой функции HAL для управления USB-Host. В HAL опять же предполагается, что функция MX_USB_HOST_Process() располагается в главном цикле (суперцикле) программы. Понятно, что любая длительно выполняющаяся функция в суперцикле блокирует вызовы MX_USB_HOST_Process(), и часть USB данных от камеры теряется. Чтобы избежать этого, мне пришлось вынести обработку данных от камеры в прерывание от предварительно настроенного таймера.

Камера передает данные в Isochronous пакетах. По стандарту UVC, каждый пакет содержит заголовок (обычно 12 байт длинной) и полезные данные. Для нас в заголовке важным является только второй байт — он содержит в себе битовые флаги, несущие информацию о пакете.
Один из битов: EOF — показывает, что текущий пакет данных является последним в кадре. Другой бит: FID — переключатся при смене кадра. Используя эти биты, можно обнаруживать начало и конец кадра. При получении пакета с полезными данными (не все пакеты их содержат), программа копирует их в кадровый буфер. В своей программе я реализовал двойную буферизацию принятых данных (то есть используются два кадровых буфера).

После того, как весь кадр получен, его нужно отобразить на экране.
В случае, когда используется режим несжатых данных YUY2 это сделать достаточно просто — каждые 4 байта данных из кадрового буфера соответствуют двум пикселям изображения.
Отмечу, что YUY2 изображение размером 160×120 занимает 38400 байт в RAM. В принципе, если для работы с изображением не нужна цветовая информация, то половину передаваемых камерой данных можно отбрасывать, за счет чего размер кадрового буфера сокращается вдвое.

В случае MJPEG обработка данных сложнее — каждый кадр представляет собой JPEG изображение. Для декодирования полученных изображений я использовал библиотеку TJpgDec от elm-chan. Однако и здесь все не так просто — тут я просто процитирую Википедию:

Таким образом, мне пришлось доработать декодер MJPEG, чтобы он брал предварительно подготовленные DHT данные из Flash памяти.

Получившаяся производительность в режиме YUY2 — с учетом отрисовки на экране:
160×120 — 15 FPS.

Производительность в режиме MJPEG — с учетом отрисовки на экране:
160×120 — 30 FPS.
320×240 — 12 FPS.
640×480 — 4 FPS.

  • Не все камеры работают в UVC режиме. Мне несколько раз встречались подобные камеры.
  • Встроенный в STM32 USB Host работает только в Full Speed (FS) режиме. Мне попадались камеры, которые вообще не передавали никаких данных в этом режиме. Причем именно такую камеру я подключил к контроллеру первой, и долго пытался понять, почему ничего не работает. Позже я подключил ее к ПК, у которого в BIOS был отключен USB 2.0, и убедился, что с ним камера тоже не работает. В режиме HS камера с ПК работала без проблем.
  • Поддерживаемые разрешения для режимов FS и HS различаются (в зависимости от режима камера передает разные дескрипторы), в режиме FS их может быть меньше.
  • В режимах YUY2 и MJPEG варианты разрешения могут быть различными.
Читайте так же:
Как утеплить потолок на веранде изнутри

Также я написал пример подключения камеры с STM32F4-DISCOVERY. Поскольку у меня не было экрана, который можно было бы подключить к этой плате, то в этом примере я просто отправляю принятый кадр на ПК. Для этого используется специальный отладочный механизм IAR (используя yfuns.h).

И напоследок:
В случае использования режима YUY2 полученное изображение на ПК можно посматривать при помощи программы 7yuv (нужно выбрать в ней режим YUV422 YUYV).

Для анализа дескрипторов устройств, подключенных к ПК очень удобно использовать утилиту USBView от Microsoft.

На всякий случай — подробная статья про подключение USB камеры к ARM Cortext-M3 SAM3X.

Как подключить модуль камеры OV7670 к Arduino

Транслируем изображение в реальном времени с помощью модуля камеры OV7670 на 1,8-дюймовый TFT ЖК-экран с помощью Arduino IDE.

Шаг 1. О проекте

В этом уроке мы покажем как отображать видео-поток с модуля камеры OV7670 на 1,8-дюймовый TFT ЖК-экран с помощью Arduino. OV7670 — самый доступный модуль камеры, который можно использовать с Arduino, поэтому вы можете использовать его во многих проектах.

Мы подключим, настроим и получим тестовый образ от OV7670 с помощью небольшой программы, написанной в Arduino IDE. Это может стать отправной точкой для его использования в будущих проектах. В уроке мы будем использовать библиотеку indrekluuk, и мы очень благодарны разработчикам этой библиотеки.

Шаг 2. Модуль камеры OV7670

Этот модуль позволяет захватывать изображения в формате VGA (640×480). Он может выполнять некоторую начальную обработку и передавать изображения на микроконтроллеры, такие как Arduino, через интерфейс SCCB.

Модуль камеры OV7670.

Модуль камеры OV7670.

Камера позволяет формировать изображения в других форматах, таких как CIF (352×240) например. Ручная регулировка до 40×30 также возможна. Максимальная скорость передачи изображения (VGA) может достигать 30 кадров в секунду. Камера также выполняет предварительную обработку изображений, например контроль экспозиции, усиление, баланс белого и многое другое. Также поддерживаются различные варианты кодирования изображений (YUV, различные типы RGB). Передача данных осуществляется по протоколу SCCB.

OV7670 характеристики

  • Разрешение VGA (640 x 480)
  • QVGA (320 х 240)
  • CIF (352 х 240)
  • QCIF (176 × 144);
  • Скорость передачи до 30 кадров в секунду,
  • несколько способов кодирования изображения RAW RGB, RGB 565/555, YUV / YCbCr 4: 2: 2.

Шаг 3. Комплектующие

Нам понадобится очень небольшой набор комплектующих (на фото выше слева направо):

    , ,
  • OV7670,
  • Макет.

Для понимания работы TFT-дисплея обязательно посмотрите Гид по работе с TFT-дисплеями.

Шаг 4. Схема соединения

Продолжаем со сборки всех компонентов, как показано на схеме ниже.

Соединения между OV7670 и Arduino Nano:

OV7670Arduino Nano
VSYNCPIN2
XCLCKPIN3(должен быть сдвинут по уровню от 5 В => 3,3 В)
PCLCKPIN12
SIODA4 (I2C data)
SIOCA5 (I2C clock)
DO D3A0.. A3 (pixel data bits 0..3)
D4 D7PIN4..PIN7 (pixel data bits 4..7)
3.3V3.3V
RESET3.3V
GNDGND
PWDNGND

Соединения между TFT-дисплеем и Arduino Nano:

TFT DisplayArduino Nano
DCPIN 8 (5V => 3.3V)
CSPIN 9 (5V => 3.3V)
RESETPIN 10 (5V => 3.3V)
SPI dataPIN 11 (5V => 3.3V)
SPI clockPIN 13 (5V => 3.3V)
VCC5V/3.3V (в зависимости от положения перемычки на плате TFT)
BL3.3V
GNDGND

Шаг 5. Компиляция в Arduino IDE

Скачать все нужные файлы вы можете на GitHub здесь.

  • Скопируйте «src/lib/LiveOV7670Library» и «src/lib/Adafruit_GFX_Library» в папку Arduino «libraries» (если у вас уже есть «Adafruit_GFX_Library», то вам не нужно её копировать).
  • Откройте «src/LiveOV7670/LiveOV7670.ino» в Arduino IDE.
  • Select Tools -> Board -> Arduino Uno/Nano.

Шаг 6. Настройка программы

Вы можете выполнить все действия шаг за шагом согласно скриншотам.

Сначала идем на Github.

Нажмите «Скачать ZIP» (Download ZIP), чтобы загрузить все файлы.

После загрузки разархивируйте файлы в нужную папку.

Откройте разархивированную папку и перейдите в каталог: LiveOV7670-mastersrclib. Скопируйте две папки в вашу библиотеку (Library) Arduino.

Перейдите в LiveOV7670-mastersrcLiveOV7670. Откройте файл с именем setup.h.

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

Когда установлен Пример 1, камера передает изображение непосредственно на ЖК-дисплей, который подключен через интерфейс SPI с использованием библиотеки LiveOV7670Library.

Установите Пример 1 для live-потока TFT.

Далее откройте файл LiveOV7670.ino.

В нижней правой части экрана выберите плату Arduino и порт (Port).

Загрузите код сверху без каких-либо изменений.

Вы увидите уведомление о том, что программа компилируется, как показано выше.

Шаг 7. Заключение

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

4 комментария

Уважаемый автор, все сделала, как вы сказали, но после загрузки ошибка компиляции (см. далее). Что я делаю не так?
Arduino: 1.8.13 (Windows Store 1.8.42.0) (Windows 10), Плата:»Arduino Nano, ATmega328P (Old Bootloader)»

In file included from C:Users����DocumentsArduinolibrariesAdafruit_GFX_LibraryAdafruit_SPITFT.cpp:36:0:

C:Users����DocumentsArduinolibrariesAdafruit_GFX_LibraryAdafruit_SPITFT.h:244:23: error: no members matching ‘Adafruit_GFX::drawRGBBitmap’ in ‘class Adafruit_GFX’

using Adafruit_GFX::drawRGBBitmap; // Check base class first

Ошибка компиляции для платы Arduino Nano.

Этот отчёт будет иметь больше информации с
включенной опцией Файл -> Настройки ->
«Показать подробный вывод во время компиляции»

Warning: Use of undefined constant comment — assumed ‘comment’ (this will throw an Error in a future version of PHP) in /var/www/u0804506/data/www/arduinoplus.ru/wp-content/themes/arduino/inc/arduino-comments.php on line 37
Ответить

Я все сделала. У меня после долгих мытарств (меняла наименование пользовательской папки на английский язык) все-таки программа загрузилась. Но на экране — рябь , просто бегут полосочки по экрану. Сам экран реагирует на освещение — когда подношу к камере лампу, полоски становятся светлыми. В чем может быть дело? Почему нет целостного изображения? Использовала точно такие как у вас детали.

Warning: Use of undefined constant comment — assumed ‘comment’ (this will throw an Error in a future version of PHP) in /var/www/u0804506/data/www/arduinoplus.ru/wp-content/themes/arduino/inc/arduino-comments.php on line 37
Ответить

У меня все заработало (поправила контакты, перезагрузила скетч). Жаль, что вы так необщительны, но все равно спасибо. А сделайте еще на какой-нибудь урок на другой TFT экран. Я хочу большой экран, ну хотя бы 6-7 дюймов.

Warning: Use of undefined constant comment — assumed ‘comment’ (this will throw an Error in a future version of PHP) in /var/www/u0804506/data/www/arduinoplus.ru/wp-content/themes/arduino/inc/arduino-comments.php on line 37
Ответить

Здравствуйте, а можете поделиться проектом, хотел подробно узнать, спасибо

Видеокамера OV7670. Введение.

Обработка изображений — это весьма востребованная сторона разработок эмбеддеров. Охранно-следящие устройства и видеодокументирование, мультимедиа и связь — только некоторые из областей применения, где требуется обработка изображений. Конечно не секрет, что для разработчиков-любителей, за редким исключением, цена комплектующих имеет важное, порой решающее значение. Поэтому неудивительно, что при закупках народ ориентируется в первую очередь на недорогие комплектующие. Примером недорогой видеокамеры служит OV7670, купленная на Деалэкстиме за 12,90 $. Знаю, товарищи, знаю, что на ебее она ещё дешевле 🙂 Вот она, камера, у нас в руках.
OV7670_cameraДальнейшая задача — снять с неё изображение и вывести его на подходящий экранчик — такой вот минимум. Причём не будем задаваться целью выжать из камеры всё, что ей предначертано. Снять и вывести изображение — для начала хватит! Ну, а потом уже, после понимания сути, продолжим извращаться во всех ракурсах 🙂 Перед началом рассуждений повторюсь: для понимания излагаемого материала необходимо иметь определенные познания и навыки — здесь не будут пояснений в плане, что такое пиксель или I2C, предполагается, что читатель слегка подготовлен. Ну, с Богом!
С чего же начать? Ну, наверное, погуглить и почитать, что о ней пишут, воспользоваться, так сказать, наработанным опытом. Мне здорово помогла вот эта статья, например. Там, кстати, есть ссылка на даташит изделия.
………………………………………………………………..
OV7670 формирует изображение с максимальным разрешением 640 х 480 и может выдать его со скоростью до 30 кадров в секунду. Видеоинтерфейс использует синхроимпульсы по кадрам VSYNC, по строкам HREF и по пикселям PCLK. Данные пикселя, представляющие собой закодированную информацию об его цвете, выдаются по 8-ми разрядному параллельному интерфейсу D7-D0 по тактам PCLK. �?мейте в виду, что один пиксель не равен одному байту. В случае кодировки RGB данные о цвете пикселя выдаются в двух байтах, а для YCbCr -кодировки — там посложнее, но об этом после.
Для OV7670 существуют множество настроек. К примеру можно использовать такие форматы кадра: — VGA (640 х 480); — QVGA (320 х 240); — CIF (352 х 240); — QCIF (176 × 144); — ручное масштабирование.
Как уже упоминалось имеется две основных кодировки цвета пикселя. Это YCbCr — кодировка, с которой я пока ещё досконально не разбирался, и уже известная мне RGB — кодировка. RGB доступна в следующих вариантах : RGB565, RGB555 и RGB444. Цифры обозначают количество бит на каждый цвет. К примеру RGB565 — 5 бит на красный, 6 бит на зеленый и 5 бит на синий. А в передаваемых через 8-ми разрядный параллельный порт D7 — D0 двух байтах одного пикселя расстановка при этом будет следующая:

Для RGB565: Для RGB555:

Для RGB444:

Кроме указанных есть ещё множество настроек (регулировки усилений по цветам, уровни серого, полярности сигналов, внутренняя PLL и пр.) К некоторым мы ещё вернёмся в будущем, а кому интересно сейчас — читайте даташит.
Рассмотрим разъём 9×2 для подключения OV7670 :
VDD — питание;
GND — общий;
SDIOC — (вход) тактовый сигнал последовательного интерфейса SCCB управления камерой;
SDIOD — (вход/выход) информационный сигнал (данные) последовательного интерфейса SCCB управления камерой;
VSYNC — (выход) импульс кадровой синхронизации;
HREF — (выход) импульс строчной синхронизации;
PCLK — (выход) тактовый импульс выдачи байта с параллельного порта D7 — D0;
XCLK — (вход) главный тактовый импульс для работы OV7670;
D7 — D0 — 8-ми битный параллельный видеовыход;
RESET (Сброс) — вывод аппаратного сброса камеры;
PWDN — вывод аппаратного включения/выключения камеры.

Как следует из описания разъёма управление настройками камеры осуществляется через последовательный интерфейс SCCB. Не стоит волноваться, оказывается этот интерфейс — полный аналог I2C ! Соответственно SDIOC — это сигнал SCL, а SDIOD — SDA.
Теперь убедимся в работоспособности OV7670 . Это довольно просто. Я использовал, например, макетку STM32F100C4. Подал с неё на камеру питание 3,3 В, а с вывода MCO вдул 24 МГц на вход XCLK. . Теперь с помощью осциллографа следует убедится в наличии сигналов на: — выводе PCLK — там будут те же 24 МГц; — выводе VSYNC30 Гц (настройки по умолчанию 30 кадров с секунду); — выводе HREF приблизительно 14,4 кГц (по умолчанию формат VGA 640х480, т.е 30 кадров по 480 строк — 30х480=14400); — выводах D7-D0 — там должны быть видны информационные посылки (т.е. изменения нулей и единиц)… Is it so? Поздравляю — Ваша камера вроде бы рабочая 🙂 Для ясности видеоинтерфейса приведена осциллограмма из даташита.
Тут, я думаю вопросов не должно возникать. Единственное, что путает мысли — это осциллограмма HSYNC, ведь такого сигнала на выходе камеры нет! Просто не обращайте на неё внимание — это внутренний сигнал OV7670. Он показан здесь, похоже, из даташитов на подобное устройство — не рисовать же разработчикам даташиты для каждой модели камеры 🙂 Я вообще хотел его в Паинте стереть, но подумал, что будут вопросы.

А сейчас выложу мои размышления по поводу подключения OV7670 к микроконтроллеру и непосредственно её работы… Я не претендую на их абсолютную научность и непогрешность, т.к не являюсь специалистом в области видеотехники. Может быть будут какие-то неточности и ошибки, в т.ч. и в терминах — не судите строго.
1-й способ, который напрашивается сразу — это прямое подключение видеосигналов камеры к дисплею. Микроконтроллер в таком случае будет настраивать режимы работы видеокамеры и дисплея и управлять ими. Рисунок ниже пояснит мои слова:
Очевидно, что это самый простой способ, т.к. микроконтроллеру не нужно производить захват и обработку видеосигнала. Одна проблема — дисплеев с такой настройкой по данным я не встречал. Строчные и кадровые — без проблем, а вот формат входных данных не тот

2-й способ — подключение всех сигналов с видеокамеры на микроконтроллер, дальнейшая их в МК обработка, приведение к необходимому формату и отправка на дисплей для отображения. Параллельно с обработкой видео контроллеру нужно ещё и управлять камерой и дисплеем. Рисунок ниже:
Этот способ самый «тупой», хотя и самый гибкий. Можно не заморачиваться с форматом входных и выходных данных, следовательно можно использовать различные типы камер и дисплеев. Но недостаток существенный — контроллер должен быть очень»шустрым», чтобы на лету «ловить», «переваривать» и «выплёвывать» видео в дисплей! AVR-ка вряд ли потянет.

Придумался мне ещё один, 3-й способ. В общем он похож на 1-й, но для преобразования данных D7-D0 и их тактовых импульсов PCLK можно применить несложную схемку, собранную на простых логических элементах, регистрах и триггерах. Ну, по типу, как организована связь с внешним ОЗУ у ATmega 8515, 64, 128.

Предполагаю, что это наиболее оптимальный способ подключения видеокамеры к дисплею. Довольно гибкий (логикой можно преобразовывать данные к любому необходимому виду, причём «на лету») и нетребовательный к производительности микроконтроллера, т.к. не нужно захватывать и преобразовывать видео (думаю Мега48 потянет).
Фиг его знает, может я тут ахинею несу ? Тогда прошу почтенных видеогуру меня направить на путь истинный А сейчас я, пожалуй, возьму свою видеокамеру OV7670, макетку с ATmega48, дисплей uDisp320240 и попытаюсь вывести хоть какое-то изображения с камеры на дисплей по 2-му способу. Об этом в следующей статье.

STM32F4. Урок 27 — Подключение камеры OV9655

В данной библиотеке описывается подключение модуля цифровой камеры 1,3МПикселя (на базе контроллера OV9655) с использованием DMA через интерфейс DCMI к отладочной плате TM32F4 Discovery.

Стоимость модуля на Ebay составляет примерно 15 евро. Камера имеет разрешение 1280х1024 (SXGA) и глубину цвета 16 бит. Связь с чипом осуществляется через I2C (400кГц максимум), а данные изображения передаются по 8ми битной шине DCMI. Поддерживаются 15 и 30 кадров в секунду.

В данной статье автор реализует просмотр изображения на ЖК-дисплее, на данный момент имеются библиотеки для работы с QVGA дисплеем (320×240) и QQVGA (160×120). Передача осуществляется через DMA для разгрузки процессора и более плавного отображения на дисплее (на данный момент картинка отображается зеркально). Версия библиотеки 1.1 позволяет сохранять снимки. Если выбрано разрешение 160х120 пикселей, снимок может быть сохранен в оперативную память. Полученное изображение может быть в итоге может быть преобразовано из массива в памяти в BMP формат с помощью библиотеки “UB_OV9655_RAM2BMP”. Данные могут быть переданы через UART (для этого требуется подключение UART-библиотеки).

Примечание: некоторые DCMI-порты процессора на модуле Discovery уже заняты кодеком CS43L22 и акселерометром LIS302 (PA4, PA6, PB6, PB9, PC7). Проблем с работой камеры замечено не было, однако, две микросхемы, наверное, одновременно не могут быть использованы.

Важное замечание по отладочной плате: При использовании отладочной платы необходимо переподключить два пина. Стандартное подключение DCMI (CON6) предусматривает использование D2 и D3 на пинах процессора PE0 и PE1. Но эти порты используются для обработки прерываний LIS302 и линии всегда подтянуты к низкому уровню!! Автор подключает эти линии к выводам PC8 и PC9, которые также являются линиями D2 и D3 шины DCMI.

Еще одно замечание: 18 пиновый разъем CON6, помеченный как OV9655, не совсем совместим по пинам, поэтому необходимо припаять переходник. Модуль камеры требует подачи частоты (10-48МГц). В примере используется генератор 16МГц, по умолчанию используется 24МГц, но у автора его не было:-) Для работы с дисплеем и I2C-шиной используется две библиотеки «STM32_UB_LCD_ST7783» и «STM32_UB_I2C1». Для отображения на QQVGA используется библиотека версии 1.5.

Пример исполнения:

Используемые выводы и DMA:

Требуемые библиотеки:

Подключаемые модули CooCox-IDE: DCMI, DMA
Поддерживаемые библиотеки: STM32_UB_I2C1, STM32_UB_LCD_ST7783

Перечисления:

Функции:

Пример использования:

В приложении проект CooCox и отдельная библиотека для использования в других проектах. Автор оригинала статьи просит задавать вопросы на его сайте на немецком или английских языках.

голоса
Рейтинг статьи
Ссылка на основную публикацию