Video на stm32duino: ov7670 + stm32f103c8t6 + ili9341
- Войдите на сайт для отправки комментариев
Ср, 22/08/2018 - 11:29
Скажу честно: зачем мне может понадобиться подобная конструкция, я не знаю. Сам на форуме несколько раз заявлял, что Ардуино и видео - вещи несовместимые. Но вот соблазнился на низкую цену и заказал себе камеру (вдруг когда-нибудь пригодится), а когда получил, обнаружил, что проверить работоспособность не так просто.
В общем, проект не является утилитарным, а подразумевает исключительно спортивный интерес.
Итак, что имеем:
- самую дешевую камеру (что-то в районе $2),
- самый дешевый дисплей 320х240 - увы, только в виде шилда для Uno (все другие варианты - дороже).
- AVR вряд ли подходят по производительности, на Due неудобно (и не полностью) разведены порты, Due Core - жаба душит, а BluePill - самый раз по всем позициям, особенно, учитывая, что это самый дешевый 32-разрядный контроллер.
Итак, получилась конструкция из трех самых дешевых компонент.
Кстати, 3 штучки BluePill в свое время заказал, но так и не удосужился их даже попробовать. Теперь, наконец, руки дошли. Один, кстати, оказался неисправным :(
По логике, можно было бы просто соединить выход камеры с входом дисплея, предварительно настроив их так, чтобы они понимали сигнал друг друга. А контроллер задействовать только в шине управления. Тогда и Pro Mini за глаза хватило бы. Но как же спортивный интерес? Опять же, если мы говорим об обработке, то процесс выглядит так: чтение_с_камеры->обработка_в_контроллере->вывод_на_дисплей. Так что, чтобы иметь возможность как-то включить обработку, нужно по меньшей мере иметь первую и последнюю стадии. Вот этим, собственно, и займемся.
Ко всему оказалось, что BluePill еще и оптимален по количеству потов ввода-вывода:
- для камеры нужно: 8 - шина данных, 2 - шина SCCB, 4-5 - шина управления,
- для дисплея нужно: 8 - шина данных, 4-5 - шина управления,
итого: 26-28 контактов.
У BluePill всего 35 контактов, некоторые из которых, правда, 8 используются по другому назначению:
- PB2 - используется в качестве BOOT1 - на гребенку не разведен,
- PA13-PA14 - используются ST-Link - на гребенку не разведены,
- PA11-PA12 - используются USB - на гребенке присутствуют,
- PC13 - используется для светодиода-индикатора - на гребенке присутствует,
- PC14-PC15 - соединены с кварцем на 32768 для RTC - на гребенке присутствуют.
т.е. получается, что всего в обрез.
По факту, решил отказаться от RESET на дисплее, благо для этого есть команда. Хотя, вероятно, лучше было бы отказаться от сигнала READ дисплея, т.к. он включен через преобразователь уровня, а подавать на 3-вольтовый контроллер 5 Вольт сразу по 8 каналам - чревато.
При проектировании распиновки выяснилась одна неприятная особенность: если мы хотим передавать данные с камеры на дисплей без дополнительных манипуляций, номера пинов шины данных порта А должны соответствовать номерами пинов шины данных порта В, причем, в порте В занят один пинов из младшей половины, а в порте А - несколько пинов из старшей. Поэтому шину данных пришлось расположить на пинах с 3 по 10.
Вот что получилось в результате:

Для отладки на схеме предусмотрел несколько точек подключения логического анализатора или осциллографа (показаны кружками), а также немного разделил выход данных SCCB контроллера и камеры - опять же для облегчения отладки.
Посмотрев на дохленький стабилизатор питания BluePill не рискнул нагружать его еще и камерой, поэтому предусмотрел внешний стабилизатор.
andriano. жду продолжения. DMA будет?
Буду пробовать несколько вариантов. Среди них, возможно, будет и DMA. С stm32 работаю меньше двух недель, но пощупать DMA желание есть. Пока есть только опыт программирования DMA на IBM PC под DOS.
Мне кажется DMA тут не светит, c обычными портами оно не умеет общаться.
С какого это перепуга??? Не факт что будет быстрее с ДМА... из-за латентности... но работать будет...
С какого это перепуга??? Не факт что будет быстрее с ДМА... из-за латентности... но работать будет...
мб из за того что DMA не умеет работать с GPIO
мб если настроить
для камеры :
DMA_CHx_SrcAddr = &GPIOA (у GPIO регистра есть адресс)
DMA_CHy_DstAddr = buffer;
для экрана :
DMA_CHz_SrcAddr = buffer
DMA_CHw_DstAddr = &GPIOB
мб из за того что DMA не умеет работать с GPIO
Похоже, что действительно можно работать с GPIO, но не как с переферией, а как с адресным пространством. Хорошо бы кто нибудь разобрался и выложил примерчик для stmduino :-))
Похоже, что действительно можно работать с GPIO, но не как с переферией, а как с адресным пространством.
Да, на STM32 вся периферия смаплена в области памяти и к любому GPIO можно обращаться, просто читая или записывая данные по определенному адресу.
К сожалению, на практике пока не пробовал :(
мб из за того что DMA не умеет работать с GPIO
Это DMA не умеет работать с GPIO... или вы???
Умеет работать... и точка...
К сожалению, на практике пока не пробовал :(
Хорошая вещь... кстати...
Первым делом после пайки платы подключил к ней дисплей.
Вывод на дисплей - одна из важных частей проекта, нужно було его как-то пощупать и пооптимизировать.
Вот что получилось:
Как выяснилось, дисплей оптимизирован под групповые операции, т.е. можно определить прямоугольный регион, а дальше просто писать туда данные, и он будет последовательно (строка за строкой) заполняться.
Общие результаты таковы:
Проверьте -Ofast. Я вроде это уже советовал.
Спасибо, дойдут руки - проверю. Но для этого надо ковырять IDE, как там провесить команды, не выведенные в меню. Пока что есть более интересное занятие.
И, кстати, мне не попадалась таблица команд с растактовкой для stm32f103c. Ни у кого нет подходящей ссылочки?
Значит... либо ардуина шалит... либо с ключами ЖЦЦ не разобрались... На Кейле всё нормально... начиная с -O1 и выше...
И, кстати, мне не попадалась таблица команд с растактовкой для stm32f103c. Ни у кого нет подходящей ссылочки?
здесь
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf
Глава 18
Спасибо.
Ну а с ключами gcc, а также вообще с тем, как до них добраться через Arduino IDE, я действительно разбираться даже не начинал.
Ну и о том, а не пора ли переходить на Кейл либо какую другую среду, тоже задумывался, но пока к единому мнению не пришел.
И включаемый файл (правда, слепленный не по фен-шую)
А два остальных файла уже публиковались в сообщении №5.