controller_m30 1 9 октября, 2013 Опубликовано 9 октября, 2013 (изменено) · Жалоба Доброго всем времени. Бьюсь с получением данных от камеры в формате JPEG с помощью DCMI. Проблема такая. Байты от камеры принимаются иногда по два одинаковых подряд. Расстояние между "неправильными" байтами примерно 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 изображению. Всё очень чётко. Вот пример. Различия между двумя режимами такие: 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: Изменено 10 октября, 2013 пользователем controller_m30 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 10 октября, 2013 Опубликовано 10 октября, 2013 · Жалоба У вас 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
controller_m30 1 10 октября, 2013 Опубликовано 10 октября, 2013 (изменено) · Жалоба У вас DMA2 еще что-то делает, помимо обслуживания камеры? В errata описана проблема при одновременной работы DMA2 с AHB и APB периферией. Спасибо, интересный вариант. DMA2 больше ничего не делает, работает только с DCMI, и отправляет данные в RAM. Во время приёма кадра нет никакого обмена с другой периферией, нет разрешенных прерываний, и процессор занят только опросом регистра статуса и контроля в DCMI. Но что-то в этом есть. Выходит DMA2 или DCMI могут терять данные при каких-то условиях. Возможно на низкой частоте приёма данных, эта тенденция себя не проявляет, а когда камера выдаёт JPEG сопровождаемый сигналом PCLK максимальной частоты - тут пропуски данных и происходят... Изменено 10 октября, 2013 пользователем controller_m30 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ave! 0 4 апреля, 2016 Опубликовано 4 апреля, 2016 · Жалоба controller_m30, у вас с камерой в jpeg что-то получилось? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
let's see 0 5 апреля, 2016 Опубликовано 5 апреля, 2016 (изменено) · Жалоба Заказал OV5640 Amazon по получении попробую прицепить к MCBSTM32F400. Посмотрим что получится. FYI: Check it out Изменено 5 апреля, 2016 пользователем pitt Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
controller_m30 1 5 апреля, 2016 Опубликовано 5 апреля, 2016 · Жалоба controller_m30, у вас с камерой в jpeg что-то получилось? Получилось. Оказалось что процессор и шина не были разогнаны до приличной скорости, и работали на дефолтной частоте. Потому DCMI так глючило. Когда удалось-таки разогнать "камень", то DCMI заработал как надо. Моих познаний всё-равно не хватало для правильной настройки всех генераторов частоты (как я ни пытался), и я воспользовался программкой от STM - не помню как называется, но она в виде макроса для Excel. Без неё, оказывается, очень трудно отстроить все делители-умножители правильным образом. Выяснилось это правда только через пару месяцев, и я забыл отписаться здесь. В этой ветке форума, темы двухмесячной давности "улетают" на много страниц назад... :crying: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться