Перейти к содержанию
    

STM32F2хх DCMI режим JPEG

Доброго всем времени.

Бьюсь с получением данных от камеры в формате JPEG с помощью DCMI.

Проблема такая. Байты от камеры принимаются иногда по два одинаковых подряд.

6f4c21b2005c.png

Расстояние между "неправильными" байтами примерно 16-18 "правильных" байт. Приём данных от DCMI ведётся с использованием DMA2. Приоритет DMA2 максимальный. Настройки FIFO DMA2 использовал разные: выключено, и заполненность по всем 4 уровням. Частота сигнала камеры PCLK 13 мГц. Данные размещаются в RAM контроллера с адреса 0x20000000.

Шины AHB APB1,2 настроил по максимуму: AHB=120мГц, APB1=30мГц APB2=60мГц.

 

Что в работе контроллера может мешать приёму по DMA? Может ли DMA2 конфликтовать с какими-то шинами, участками памяти, или процессами контроллера? Или может не DMA а модуль DCMI может чем-то прерываться, или получать ложный сигнал срабатывания - ну и принимать иногда по два байта сразу? Или может частота 13 мГц слишком высокая? Может надо процессор на время приёма кадра как-то останавливать, чтоб он совсем никак не вмешивался в процесс приёма (при активизации DMA2 и DCMI процессор опрашивает регистр контроля DCMI_CR и регистр статуса DCMI_SR на предмет окончания приёма кадра, или возникновения ошибки).

 

Дело ещё и в том, что камера работает и в режиме видоискателя, и тогда выдаёт несжатые данные в формате YCbCr. И в этом режиме данные принимаются чётко, без всяких повторов. Я не могу найти повторы ни визуально, ни по выводимому на LCD изображению. Всё очень чётко. Вот пример.

4a5cff27ea06.png

Различия между двумя режимами такие:

1. Камера в режиме видоискателя выдаёт сигнал PCLK с частотой примерно 2,5 мГц, а в режиме JPEG 13 мГц.

2. Модуль DCMI в контроллере соответственно настраивается на режим несжатых данных (бит 3 DCMI_CR=0) и на режим JPEG (бит 3 DCMI_CR=1).

Собсно я пробовал принимать данные JPEG и в обычном режиме - разницы никакой, точно так-же принимаются двойные байты, с примерно такой-же дистанцией между ними.

3. В режиме видоискателя данные идут ровным потоком и распределены равномерно между двумя строчными импульсами, а в режиме JPEG камера выдаёт данные некоторыми порциями, между которыми сигнал PCLK остаётся неактивным.

 

Вот две картинки с логического анализатора Saleae Logic. Верхняя - это режим видоискателя. Нижняя - формат JPEG, в котором возникают проблемы. К сожалению, анализатор Saleae Logic не поддерживает сигналы выше 12 мГц и потому я не стал приводить сигналы под большим увеличением - всё равно они недействительны. Но для общей оценки вполне годится. :rolleyes:

69b3e7b3907d.png

Изменено пользователем controller_m30

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У вас DMA2 еще что-то делает, помимо обслуживания камеры?

В errata описана проблема при одновременной работы DMA2 с AHB и APB периферией.

When the DMA2 is managing AHB Peripherals (only peripherals embedding FIFOs) and

also APB transfers in a concurrent way, this generates a data corruption (multiple DMA

access).

When this condition occurs:

● The data transferred by the DMA to the AHB peripherals could be corrupted in case of a FIFO target.

● For memories, it will result in multiple access (not visible bythe Software) and the data is not corrupted.

● For the DCMI, a multiple unacknowledged request could be generated, which implies an unknown behavior of the DMA.

AHB peripherals embedding FIFO are DCMI, CRYPTO, and HASH. On sales types without

CRYPTO, only the DCMI is impacted. External FIFO controlled by the FSMC is also

impacted.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У вас DMA2 еще что-то делает, помимо обслуживания камеры?

В errata описана проблема при одновременной работы DMA2 с AHB и APB периферией.

Спасибо, интересный вариант.

DMA2 больше ничего не делает, работает только с DCMI, и отправляет данные в RAM. Во время приёма кадра нет никакого обмена с другой периферией, нет разрешенных прерываний, и процессор занят только опросом регистра статуса и контроля в DCMI.

 

Но что-то в этом есть. Выходит DMA2 или DCMI могут терять данные при каких-то условиях.

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

Изменено пользователем controller_m30

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Заказал OV5640 Amazon по получении попробую прицепить к MCBSTM32F400. Посмотрим что получится.

FYI: Check it out

Изменено пользователем pitt

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

controller_m30, у вас с камерой в jpeg что-то получилось?

Получилось. Оказалось что процессор и шина не были разогнаны до приличной скорости, и работали на дефолтной частоте. Потому DCMI так глючило. Когда удалось-таки разогнать "камень", то DCMI заработал как надо.

Моих познаний всё-равно не хватало для правильной настройки всех генераторов частоты (как я ни пытался), и я воспользовался программкой от STM - не помню как называется, но она в виде макроса для Excel. Без неё, оказывается, очень трудно отстроить все делители-умножители правильным образом.

 

Выяснилось это правда только через пару месяцев, и я забыл отписаться здесь. В этой ветке форума, темы двухмесячной давности "улетают" на много страниц назад... :crying:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...