Нужна помощь с HAL, DCMI и OV7670

Flodejr
Пт 06 октября 2017 г., 4:22 утра
Привет,

У меня есть установка с платой с голой металлической STM32F407VGT6, и она подключена к выводам OV7670 через DCMI и I2C и дисплей ST7735 через SPI. Когда я отлаживал кодом, я мог видеть полученные данные, и на дисплее есть несколько шумных пикселей. Поэтому я проверил, закрыв крышку на OV7670 и исследовал буфер. Буфер захвата показывает 0x7fff повсюду, хотя мой выбранный выходной формат RGB565.

У меня есть еще одна настройка на использовании синей таблетки STM32F103 с OV7670 и ST7735, и она использует те же настройки для OV7670 и ST7735, но он использует код Arduino от Indrekluuk, и он отлично работает идеально. Разница между ними заключается в том, что 1) STM32F103 не имеет DCMI, поэтому он использует перенос байта от OV7670 в ST7735 напрямую.

Я пробовал всевозможные способы, но кажется, что DCMI всегда даст мне 0x7fff, который близок к белым, когда он должен быть черным, когда используется DCMI.

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

Rogerclark
Пт 06 октября 2017 г. 7:22 утра
Существует поток об использовании OV7670 для ЖК -дисплея на основе ILI9341 SPI.

Stevestrong проделал большую работу над этим, чтобы улучшить код из Indrekluuk, чтобы он использовал DMA для чтения данных с камеры (на F103C8)

К сожалению, последний код Стива, кажется, работает только на его установке оборудования, и он работает только периодически для меня.

В настоящее время я использую модифицированную версию какого -то старого кода, опубликованного Стивом в качестве zip -файла в эту ветку, и, похоже, для меня работает нормально, но я знаю некоторых других людей, например,. @kozcap по -прежнему есть проблемы, даже с кодом, который работает для меня

Я также написал некоторый код, чтобы сохранить содержимое ILI9341 на SD -карту (используя функцию ReadPixels, написанную Stevestrong)
Но я думаю, что я единственный человек, который в настоящее время, кажется, использует этот код

Я также написал немного кода для чтения ЖК -дисплеев и отправить кадр через сериал на ПК, где я также написал программу просмотра на основе Python
(Я также опубликовал все код для этого на форуме, поэтому, если вы копаетесь вокруг, вы найдете его) ;-)

Стивестронг
Пт 06 октября 2017 г. 9:17
Если вы в целом получите 0x7fff, похоже, что бит данных 15 не правильно (или каким -то образом сократится до GND), проверьте его еще раз.
В качестве альтернативы вы можете сначала проверить, переключается ли этот бит при настройке как вывод GPIO, это докажет, что проводка в порядке.

Flodejr
Пт 06 октября 2017 г. 10:19
[Стивестронг - Пт 06 октября 2017 г. 9:17 утра] - Если вы в целом получите 0x7fff, похоже, что бит данных 15 не правильно (или каким -то образом сократится до GND), проверьте его еще раз.
В качестве альтернативы вы можете сначала проверить, переключается ли этот бит при настройке как вывод GPIO, это докажет, что проводка в порядке.
Физический порт имеет ширину всего 8 бит, интерфейс DCMI упадет два 16-битных слов RGB565 в 32-разрядное слово и DMA по адресу буфера памяти. Проблема в том, почему это 0x7fff, RGB565 для черного должен быть нулевым, почему он дает белый цвет? Учитывая коды инициации для камеры, такие же, как и в настройке BluePill, камера «должна« дать правильную информацию.

Для самой инициализации я написал код так, чтобы после отправки кода в камеру через I2C я прочитаю тот же регистр, чтобы убедиться, что значения соответствуют значениям. Так что я не думаю, что это проблема кода инициализации. Таким образом, единственная разница - выборки значений из 8 -битного порта на основе PixClk, HSYNC и VSYNC, а затем упаковывайте их в FIFO и отправьте по адресу буферного. Но я не знаю, что произошло между тем, что значения были изменены или несколько.

Стивестронг
Пт 06 октября 2017 г. 11:19
У вас есть код, которым можно поделиться?
Как проверить значение? Читать из буфера? Может ты прочитал Int32 ценность из буфера uint32?
Хотя ноль должен быть нулевым в любом случае...

Или это из -за настроек DCMI.
Вы используете режим синхронизации встроенных данных?
Или неправильные настройки полярности VSYNC/HSYNC?

Flodejr
Пт 06 октября 2017 г. 11:44
[Стивестронг - Пт 06 октября 2017 г. 11:19] - У вас есть код, которым можно поделиться?
Как проверить значение? Читать из буфера? Может ты прочитал Int32 ценность из буфера uint32?
Хотя ноль должен быть нулевым в любом случае...
Это мой текущий код работы в процессе работы. Очень грязный со многими различными наборами инициаторов, найденных в сети. Базовый код был сгенерирован с использованием STM32Cubemx, а файл IOC включен. Я планирую очистить его и оптимизировать после того, как я заработаю, так что... вот.

Стивестронг
Пт 06 октября 2017 г. 11:54 утра
Вы проверили прерывания DCMI, произошли будь то переполнение или другая ошибка?

Первое, что вы должны сделать, это объявить глобальные переменные, используемые в ISRS как «летучие»: volatile uint8_t frameComplete = 0; volatile uint16_t linecount = 0;

Flodejr
Сб, 07 октября 2017 г. 14:41
[Стивестронг - Пт 06 октября 2017 г. 11:54] - Вы проверили прерывания DCMI, произошли будь то переполнение или другая ошибка?

Первое, что вы должны сделать, это объявить глобальные переменные, используемые в ISRS как «летучие»: volatile uint8_t frameComplete = 0; volatile uint16_t linecount = 0;

Rogerclark
Сб, 07 октября 2017 г., 21:27
Код Steves DMA позволяет MCU читать параллельные данные и хранить в памяти, но на F103 есть место только для нескольких строк.
К сожалению, Afik DMA на F4 немного отличается от F1, поэтому я подозреваю, что код 103 Стива не будет работать на F4 без модификации

Flodejr
Солнце 8 октября 2017 г. 4:16 утра
Только что нашел что -то новое и недавнее, и я получаю некоторый прогресс. Но цвета изображения все еще неверны.

https: // www.YouTube.com/watch?v = vokasvztjlm&t = 948 с
https: // github.com/take-iwiw/digitalcamera_stm32

Стивестронг
Солнце 8 октября 2017 г. 8:53
Мой код для F1 не использует DCMI, и мой код SPI для F4 в любом случае не имеет значения здесь, потому что здесь используется программное обеспечение на основе HAL (см. Вторая ссылка).

Если я найду некоторое время, я могу попробовать сделать приложение для камеры в прямом эфире для F4, используя наше ядро ​​Libmaple.
[Flodejr - Солнце 8 октября 2017 г. 4:16] - Но цвета изображения все еще неверны.
Я бы посоветовал связаться с владельцем на GitHub, так как никто здесь, кажется, не может помочь вам с DCMI.

Rogerclark
Солнце 8 октября 2017 г. 9:18 вечера
Глядя на ReadMe на GitHub для этого проекта, спецификации не так хорошо, учитывая, что он F4 с использованием специального интерфейса камеры через DMA

Это единственный QVGA 320x240, и он управляет 5 кадром в SD.

Единственное, что может сделать, что F103C не может сделать, это сжатие JPEG, и я подозреваю, что мы сможем сделать JPEG все еще сжатие изображений, если это может быть сделано с помощью буфера 8 линий.

Но F103C8 не сможет выполнить JPEG Motion, так как это требует нескольких полных кадровских буферов (хотя я не уверен, имеет ли F4 достаточно оперативной памяти для True Motion JPEG с рамкой, отличающейся.

Flodejr
Пн, 09 октября 2017 г. 8:34
[Стивестронг - Солнце 8 октября 2017 г. 8:53] - Мой код для F1 не использует DCMI, и мой код SPI для F4 в любом случае не имеет значения здесь, потому что здесь используется программное обеспечение на основе HAL (см. Вторая ссылка).

Если я найду некоторое время, я могу попробовать сделать приложение для камеры в прямом эфире для F4, используя наше ядро ​​Libmaple.
[Flodejr - Солнце 8 октября 2017 г. 4:16] - Но цвета изображения все еще неверны.
Я бы посоветовал связаться с владельцем на GitHub, так как никто здесь, кажется, не может помочь вам с DCMI.
Вы работаете над ядром F4, просто несколько заметок о упаковке DMA в F4, я не уверен в том, ведет ли F1 одинаковый. В F4, DMA, если установить на 16 бит (половина слова), это запустит 2 переноса. Заказы будут B1, B0 в первой передаче, B3, B2 во второй передаче. Если DMA настроен на слово, это запустит одну передачу, а байт -заказ будет B3, B2, B1, B0, и это вызывает у меня серьезную головную боль, так как Cubemx не позволяет мне установить полу6 в трансферте нефифу и там Является ли примечание, чтобы сказать, что переводы нефифу-полу слов разрешены, но не гарантированная точность.

Кстати, у меня есть несколько версий спецификаций на OV7670, и есть некоторые расхождения в настройке CLKRC. Некоторые документы говорят

Внутренние часы = внешние часы/ (2*(CLKRC+1),

Но некоторые документы говорят

Внутренние часы = внешние часы/(CLKRC+1)

У меня нет возможности проверить. Вы можете прокомментировать это?

Rogerclark
Пн, 09 октября 2017 г. 9:02 утра
Я думаю, что Стив нашел трюк, чтобы просто перенести верхний байт 16 -битного регистра с помощью DMA.
Однако я не знаю, работает ли то же самое на F4, и это не задокументировано как возможное на F1....

Стивестронг
Пн, 09 октября 2017 г. 11:44
Роджер, DMA на F4 более сложный, там каждый канал имеет свой внутренний FIFO 4*32 бит.

Однако этот FIFO может быть отключен или включен.
Регистр данных DCMI должен дать байты в правильном порядке, потому что B1, B0 хранится на нижних адресах, так что, если вы настраиваете ЖК -DMA для отправки в SPI 16 бит в 16 -битном режиме, он отправит данные из того же буфера Чтобы SPI в правильной эндиане и порядке: сначала (B1, B0), а затем (B3, B2)

Если не FIFO в 16-битном режиме имеет решающее значение для DMA (я бы все равно предложил вам попробовать), то вам следует включить FIFO на.

Кстати, что именно означает Несоответствующие переводы по полукратику допускаются, но не гарантированная точность. Какая «точность» не гарантируется?

Я не мог прочитать в справочном пособии F4 о каких -либо ограничениях по программированию передачи ширины данных. Это может быть установлено на 8, 16 или 32 бит без каких -либо проблем. Указатель памяти затем будет увеличен соответственно.
Это означает, что вы должны быть в состоянии передавать данные из памяти в регистр данных SPI без какой-либо проблемы в режиме не-FIFO (прямой), либо в 8-битном режиме (который в настоящее время работает в SPI LIB).

Rogerclark
Пн, 09 октября 2017 г. 20:07
Спасибо, Стив...

Re: прямая камера на SPI

Это требует некоторой нагрузки от процессора, но SPI намного медленнее, чем эта скорость передачи данных от камеры, поэтому я не знаю, какая бы это было преимущество, если процессор не должен выполнять некоторую не связанную с этим деятельность.
эн.глин. Если данные идут прямо от камеры в ЖК -дисплей, процессор не может сделать какую -либо обработку изображений и т. Д.

Стивестронг
Вт 10 октября 2017 г. 9:15 утра
Данные не могут перейти от DCMI непосредственно к SPI, потому что периферийный до периферического режима не поддерживается DMA.
Таким образом, промежуточный буфер памяти неизбежен. И это имеет смысл, можно использовать двойную буферизацию, чтобы DCMI->Память и память->SPI переводы с DMA может работать квази параллельно.

Стивестронг
Вторник 27 марта 2018 г. 8:31
Извините, что воскресил эту ветку (Рэй не будет счастлив :? ), но у меня есть проблемы с использованием DCMI с Libmaple Core, как опубликовано здесь.
Я хотел бы только спросить @flodejr, удалось ли ему воспитывать DCMI с HAL.
Если это так, мне понадобятся значения регистров конфигурации DCMI и DMA (Stream1), чтобы сравнить их с моей настройкой, возможно, я могу найти любую ошибку.

STM32Cubemx :: STM32F030F4

[STM32Generic] F746 Discovery