Ребята,

Мне трудно заставить DCMI работать на доске Mini F4VET6, возможно, у кого -то есть какие -то подсказки/идеи, как решить проблему.
Я прочитал справочное руководство и примечание к применению от ST не менее 5 раз.
Я нашел эта ветка который использует HAL, но я не смог найти никакой разницы между этим источником и моим.
G ** gle не дал никаких соответствующих результатов, которые бы принесут мне дальше.

Что я сделал:
- Настройка камеры OV7670 (I2C работает нормально)
- Настройте контакты DCMI IO как input_af и af_mode (13)
- Настройка DCMI для работы с контрольными сигналами OV7670 (адаптированные полярности синхронизации: тройная проверка), не включен IRQ
- Настройка (+ enable) DMA2 (Stream1, Channel1) для DCMI, используя круглый буфер из 20 пикселей, не включен IRQ
- Включить DCMI
- Включить захват DCMI.

Результат:
- Line IRQ Flag установлен.
- Регистр данных DCMI->Доктор всегда 0,
- DMA вообще не учитывается (NDTR не меняется).

Я проверил, что сигналы данных синхронизации + PCLK + поступают на выводы F4.
GPIO регистрируется для задействованных булавок, которые я установил.
Я проверил значения регистров конфигурации CR DCMI и DMA, оба установлены как ожидалось. Все другие регистры DMA имеют значения, которые я установил/ожидал.

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

РЕДАКТИРОВАТЬ
- Проверьте синхронизированные сигналы с помощью DigitalRead () в основном цикле: выполнен, он отражает состояние входного сигнала.
- Проверьте DCMI IRQ:
Готово, он будет выполнен для каждой строки (H_SYNC) Falling (активация) Edge.
НО... V_SYNC не будет обнаружен!!!

Короткое обновление:
Кажется, что V_SYNC не будет обнаружен DCMI, флаг IRQ не установлен.
Это может быть причиной, по которой DMA не читает никаких данных. Бит 0 захват: захват включить
0: захват отключен.
1: включен захват.
Интерфейс камеры ждет первого начала кадра, а затем запрос DMA
сгенерировано для передачи полученных данных в память назначения.
В режиме снимка бит захвата автоматически очищается в конце
1 -й кадр получен.
В режиме непрерывного схвата, если программное обеспечение очищает этот бит, пока захват
Продолжается, бит будет эффективно очищен после окончания кадра.
Примечание. Контроллер DMA и все регистры конфигурации DCMI должны быть
правильно запрограммировано, прежде чем включить этот бит. Dcmi_cr = 0x40a1

Если я прикреплю ISR к PB7, это будет вызвано каждым падением.
Что означает, что сигнал достигает MCU.
Я проверил регистры режима PB7 и режима AF, оба настроены правильно в качестве входного штифта DCMI.

Любые мысли, почему DCMI не хочет сотрудничать с PB7?

На мини-плате F4 PB7 подключен как I2C1 SDA с EEPROM с подтягиванием 4K7. Может ли это нарушить DCMI?

F4_mini_pb7.JPG (21.22 киб) просмотрено 1448 раз

Хорошо, я думаю, что получил это.
Я изменил полярность HREF в настройках OV7670, так что HREF логична «1» во время V_SYNC (теперь оба «1»), и он начал работать!
Я думаю, что это недокументированная «функция» интерфейса DCMI.

+1 вау

DCMI работает и совершается в моем репо.

Основная проблема заключалась в том, что DCMI ожидает импульсов PCLK во время VSYNC, который был отключен проектом Live OV7670 для F1.

Еще одна проблема заключается в том, что высокий FPS (>12) Для ILI9341 может быть достигнуто только с использованием часов SPI 42 МГц. Это, однако, подтверждается только SPI1, поэтому мне пришлось переназначить булавки SPI3, чтобы использовать SPI1 из -за некоторых противоречивых контактов между нормальными булавками SPI1 и DCMI.

Следующая проблема заключается в том, что SPI с DMA не работает на 100% вместе с DCMI, система входит в его пределы, когда DCMI и SPI активируются для DMA2. Часть SPI влияет иногда на выборку DCMI, так что иногда теряются некоторые байты, вызывая уродливые артефакты на экране.
Обходной путь состоит в том, чтобы использовать «нормальный» SPI.Написать (буфер, размер) функция вместо SPI.dmasend ().
Таким образом ~ 26 кадров в секунду достигается для разрешения 320x240, что выглядит действительно красиво

Необходимы ресурсы: Sketch uses 29712 bytes (5%) of program storage space. Maximum is 514288 bytes. Global variables use 20496 bytes (15%) of dynamic memory, leaving 110576 bytes for local variables. Maximum is 131072 bytes.

Я с большим интересом читаю ваши выводы - вы проделали отличную работу! Я вижу, вы достигли 320x240@26fps - в этом настройке, где находится узкое место в системе? Это STM32F4 или дисплей? Я хотел бы транслировать монохроматическое изображение с аналогичной установкой на плату Allwinner H2/H3 над SPI. Я думаю, что мог бы переключить датчик OV7670 на формат YUV422 и прочитать только 4 бита монохроматической люмы на случай, если это ускорит вещи.

Не могли бы вы сказать, что такое ограничение «мегапиксель/второй» только STM32F4 (не включая выход SPI на другое устройство, например, дисплей и т. Д.)? 320x240@26 кадров в секунду составляет почти 2 мегапикселя (1.996) в секунду потока данных. Я предполагаю, что 640x480 может быть возможна с вашей установкой в ​​26/4 = 6,5FPS - это правильное предположение?

Хорошо, я нуб, но, надеюсь, мой вклад все равно может кому -то помочь.
Следующая проблема заключается в том, что SPI с DMA не работает на 100% вместе с DCMI, система входит в его пределы, когда DCMI и SPI активируются для DMA2. Часть SPI влияет иногда на выборку DCMI, так что иногда теряются некоторые байты, вызывая уродливые артефакты на экране. По внешнему виду вашего использования DMA дважды путем переноса из DCMI_DR в кучу, затем от кучи в SPI_DR. Вы можете просто использовать DMA для передачи из DCMI_DR в SPI_DR.

Я снова ноду, но это то, что я нашел. DMA делает только память о передаче памяти. Документы немного неоднозначно в отношении того, как они описывают DMA. Документы относятся к памяти в память, периферийную к памяти и память к периферическим переводам, все 3 типа передачи на самом деле являются переносом памяти в память, это то, что время передачи запускается. Передача памяти на память перенесет данные с адреса в DMA_SXPAR, чтобы адресовать, хранящиеся в DMA_SXM0AR как можно быстрее, насколько это возможно. Периферийные переводы в память переместят данные из адреса в DMA_SXPAR для решения, хранящихся в DMA_SXM0AR на скорости, запускаемой каналом, установленным в DMA_SXCR.

Вы должны быть в состоянии разместить адрес DCMI_DR в DMA_SXPAR, а адрес SPI_DR в DMA_SXM0AR, затем установите канал в виде DCMI, затем DMA будет перенесен из DCMI_DR в SPI_DR на скорости, запускаемой DCMI. Вам нужно будет убедиться, что камера установлена ​​на скорость достаточно медленной, чтобы она не выпустила, запустив SPI. Другой мудрый DMA будет передавать данные быстрее, чем SPI может написать их, и некоторые данные будут потеряны.

Вот небольшая игра, которую я имел в Micro-Python на плате OpenMV, где изображение дважды транслируется в сериале. Плата OpenMV импортирует изображение из камеры для обработки, затем отправляет 1 копию изображения на экран через SPI, а затем сжимает изображение в JPG и отправляет его через USB на мой компьютер, поэтому изображение отображается на как на экране SPI, так и Мой компьютер живет.

С 4 -ступенчатым процессом: 1. Импорт с камеры в память, 2. Экспорт в SPI, 3. Процесс в JPG, 4. отправить через USB На цвете 160x128 x 16bit я все еще мог бы получить 30 кадров в секунду на языке высокого уровня, как Micropython. Использование языка низкого уровня, такого как C, и просто выполнение 1 -ступенчатого процесса использования DMA для перемещения от камеры к SPI в монохромном.

Смотрите мое видео https: // www.YouTube.com/watch?v = onzi71rsgxw

Это доска M7, верно? У него подбородок F765.
F4 также должен быть способен обработать это низкое разрешение с аналогичным FPS.
Теоретически можно было отправить данные DCMI непосредственно в SPI, но я еще не пробовал их.

Это доска M7, верно? У него подбородок F765.
F4 также должен быть способен обработать это низкое разрешение с аналогичным FPS.
Теоретически можно было отправить данные DCMI непосредственно в SPI, но я еще не пробовал их. Да, я использовал M7 с помощью чипа STM32F7, но для передачи DMA, что он имеет в процессоре, не имеет значения, потому что DMA работает на отдельных цепях за пределами ЦПУ. STM32F7 сделает обработку изображения в формат JPG быстрее, поскольку это обработка.

Всегда ты только так быстро, как самая медленная бутылка, и это будет SPI. Я новичок в STM32, но если я правильно читаю документы, STM32F4 имеет максимальную скорость SPI1 42 МГц. При использовании 8 -битной серой шкалы с RES до 480 x 320, то выполнение математики, вы все равно должны получить 30 кадров в секунду с передачей DMA от DCMI в SPI, было бы интересно посмотреть, сможет ли кто -нибудь сделать это.

Если они действительно хотели более высокую частоту кадров, то просмотрели 1 чипы STM32, которые поддерживают QSPI.

Вы не можете отправить 8 -битный серогойс непосредственно в SPI, потому что AFAIK TFTS нуждаются в цветных данных RGB565 на 16 бит.

Я с большим интересом читаю ваши выводы - вы проделали отличную работу! Я вижу, вы достигли 320x240@26fps - в этом настройке, где находится узкое место в системе? Это STM32F4 или дисплей? Я хотел бы транслировать монохроматическое изображение с аналогичной установкой на плату Allwinner H2/H3 над SPI. Я думаю, что мог бы переключить датчик OV7670 на формат YUV422 и прочитать только 4 бита монохроматической люмы на случай, если это ускорит вещи.

Не могли бы вы сказать, что такое ограничение «мегапиксель/второй» только STM32F4 (не включая выход SPI на другое устройство, например, дисплей и т. Д.)? 320x240@26 кадров в секунду составляет почти 2 мегапикселя (1.996) в секунду потока данных. Я предполагаю, что 640x480 может быть возможна с вашей установкой в ​​26/4 = 6,5FPS - это правильное предположение? Был задан вопрос о потоковой передаче монохроматического изображения 320x240 на плату Allwinner H2/H3 над SPI.

Это может быть возможно на этом 320x240 Res в 8 -битной серости, чтобы достичь 60 кадров в секунду

[Flyboy74 - Пт 10 августа 2018 г. 11:05] - Был задан вопрос о потоковой передаче монохроматического изображения 320x240 на плату Allwinner H2/H3 над SPI.

Это может быть возможно на этом 320x240 Res в 8 -битной серости, чтобы достичь 60 кадров в секунду

Хороший. Это дает теоретические часы SPI около 36 МГц, который находится под пределом 42 МГц. Я хотел бы использовать OV7670, потому что это дешево, но проблема в том, что он не поддерживает простые 8 -битные серого цвета. На STM32 должно быть либо преобразование с RGB565/555, либо мне придется использовать либо YUV422, либо GRB422 непосредственно на SPI. Я боюсь, что последние двое несут худшую монохроматическую информацию, чем простой 8 -битный моно после конверсии в серого масштаба, хотя.

На самом деле я был бы доволен любыми монохроматическими данными по 4 битам Luma в YUV. В настоящее время изучение различных цветовых форматов и их конверсии в GreyScale. Я не уверен, что использование 8 бит более 16 бит данных от камеры до STM принесет больше FP с камеры - не могли бы вы сказать?

Вы можете установить пиксельные часы 20 МГц, чтобы быстрее получать данные с камеры, но вопрос в том, что вы делаете с данными?
Как сказал Flyboy74, узкое место - это извлечение данных из камера чип.
Если вы делаете бортовую обработку, имейте в виду, что ни один другой процесс DMA2 не может работать параллельно с DCMI.

Моя цель состоит в том, чтобы получить 4+ бит серого с помощью SPI как можно быстрее (подсчет мегапикселей/второй - либо QVGA при более высоком FPS, либо VGA при более низких FPS). Я получил весь HW сегодня, поэтому я надеюсь скоро экспериментировать. Я не буду использовать дисплей, у меня есть немного компьютерного зрения.

Мне также необходимо создать синхронизировать два блока (UNIT = OV7670+STM32F4), чтобы создать стерео -камеру систему. Я получил подсказку от Indrekluuk, который, вероятно, мог бы просто запустить первую камеру и подождать его vsync, затем остановите XCLK на эту камеру (= ​​пауза ее?), затем подождите, пока VSYNC на второй камере и затем снова выпустите первую камеру (= ​​снова запустите его XCLK). Как вы думаете, это сработает?

Я вижу камеру.waitforvsync и камера.Функции waitforvsyncend в коде это было бы местом в коде для реализации моего кода для синхронизации, я думаю. Если камера не может работать на фиксированных FP (я думаю, она по умолчанию снижает FPS при низком свете?) тогда синхронизация должна будет выполнять каждый кадр (из -за AEC), или мне также придется заставить оба единицы использовать одно и то же время экспозиции (запустите один мастер с AEC и непрерывно копировать его значение для рабовладельческой камеры).

Если вам нужно в SYSNC, вы узнаете начало каждого нового изображения, потому что камера будет пульсировать линию VSYNC. Вы сможете подключить линию VSYNC к STM32 и Allwinner H2 Таким образом, Allwinner узнает, когда каждый кадр начнется.

Хорошо, я думаю, есть ряд вариантов, которые вы можете изучить.

1.
Использование камеры с 8 -битной серой масштаб. OV7725, который использует OpenMV, делает Grey Scale, и я не выпустил, что OV7670 не.

Поиск OV7725 находит множество вариантов по цене, близко к OV7670 https: // www.aliexpress.com/оптом?калифорнийский ... Ule+OV7725

РЕДАКТИРОВАТЬ: Я просто быстро смотрю на таблицу данных для OV7725 и не вижу, как установить его как 8 -битную серую шкалу.

2.
Я защелкнулся, не читая форматы данных DCMI. Я вроде как, возможно, DCMI может преобразовать форматы данных на лету I.E 565RGB к 8 -битному монохромному, но не уверен, как не читал его близко, чтобы понять, что он делает.

3.
Используйте DMA, чтобы перемещать данные с камеры в кучу, затем обработайте их, чтобы получить то, что вы хотите, затем переместите их во второй раз на SPI. Это займет наибольшее количество программирования и, вероятно, самое медленное.

Хорошо, я спросил парня в OPWNMV, как получить 8 -битный серой шкалу, и они просто используют канал Y из цветового пространства YUV.

Таким образом, это означает, что вы можете использовать дешевую камеру OV7670, но вам понадобится переместить данные из DCMI в кучу, а затем обработайте ее для извлечения Y, затем отправьте их в SPI. Чтобы иметь возможность, все это, чтобы иметь возможность получить SPI с максимальной скоростью, вероятно, будет немного сложнее.

Мой разум поражает думать об этом.

При низком RES, например, 320x240, OV7670 может выполнять очень высокую частоту кадров (я думаю, справиться с какой -либо скоростью, необходимой для получения данных в кучу.

Время обработки каждого пикселя для вывода Y на SPI на скорости в MHZ может быть немного сложнее.

Я знал, что где -то это прочитал. Существует аппаратная обработка изображений, которая может преобразовать режим пикселя на лету при выполнении передачи DMA.

Прочитать руководство Crom-Art Accelerator ™ Controller (DMA2D) особенно Конвертер формата пикселей (PFC)

Если я правильно его читаю, это позволяет конвертировать из RGB565 в L8 или даже L4 на лете во время передачи DMA. Это позволило бы получить очень высокую частоту кадров от камеры DCMI до Allwinner через SPI, и как только вы поймете, как работает PFC, он вообще не должен занимать очень много строк кода вообще.

Chrome Art Accelerator доступен только на F427, F429, F469.
На F407 предполагается работать только решение, управляемое DMA, и только с ограничением, потому что 2 или более параллельных DMA2 доступны друг к другу, в то время как DCMI активен, в том смысле, что DCMI нарушается любым другим параллельным процессом DMA, вызывая артефакты на Тфу.

Хорошо, мне трудно понять, что доступно на каждом чипе, так как этот Si таблица, которую я использую
Июнь 2018 RM0090 Rev 17 1/1747
1
RM0090
Справочное руководство
STM32F405/415, STM32F407/417, STM32F427/437 и
32-разрядная MCUS на основе ARMS® на основе ARMAND ARM 32F429/439 Как я рассказываю, что доступно на том, какой чип в качестве эталонного руководства группируется все эти чипсы вместе?

редактировать: Я нашел место, которое показывает разницу https: // www.ул.com/content/st_com/en/pr ... TID = SS1577