Первое знакомство с микроконтроллерами Atmel, STM и другими.

Первый рассказ
Предэксплуатационный ремонт отладчика Atmel AVR Dragon
Цветное изображение на монохромном LCD
Конвертер растровой графики для монохромного LCD (128х64)
Дизеринг для монохромных LCD и конвертер растровых изображений
ZP-STM32 и беспроводной последовательный порт
Куда уходят миллисекунды? Способ повышения FPS
Open Logic Sniffer в действии
AVR XMEGA – разгон, вольтмод и производительность SDRAM

Здравствуйте, уважаемый zauropod.
С большим интересом читал Ваши статьи.
Хочу поблагодарить Вас за столь неординарное и увлекательное освещение темы микроконтроллеров!

Можно несколько вопросов по STM32F4?
- По CCM памяти:
1. Кроме 0 wait state при обращении, еще какие-то преимущества у CCM есть?
2. Из портов DMA туда пишет/читает данные? Или только ядро Cortex-а к ней доступ имеет?

- Еще интересно, доступ к отдельным байтам памяти, в этом чипе, с 1-2 циклами ожидания, как в прошлых поколениях ARM-ов, или ускорили?

- На счет разгона STM32F407VGT6 - возможен? Без поднятия напряжения.


Сам был бы рад выяснить все на практике, однако почта подводит, больше 2-х месяцев свою Discovery уже жду

С уважением...

neo333
И Вам новогоднее здрасьте.

Кроме 0 WS никаких преимуществ. Если хочется, то недоступность этой RAM через шину можно расценивать как недостаток, хотя это из области того, что сколько памяти не поставь - все будет мало. Но правильно ее рассматривать именно как преимущество - скоростную 0 WS RAM.

Разумеется, бит-бэндинг и DMA для этой памяти недоступны. Там лучше разместить константные таблицы, структуры, обработчики прерываний. И перенести туда стек. Для этого надо немного изменить скрипт линковщика. Тут нет единого рецепта, так как могут быть подводные камни от конкретного тулчейна, поскольку используются разные стартапы.


Как-то не совсем правильно вопрос сформулирован.
Вероятно, речь идет о доступе к данным, не выравненным по границе, соответствующей разрядности процессора. В этом случае это проблема не камня (уж такая у него архитектура), а программиста - испотльзуйте выравненные структуры, 32-битный доступ и будет вам счастье. Логические переменные, если нужны - вручную через битбэнддиапазон.
Невыравненный доступ к слову, полуслову и байту, естественно, требует лишних тактов, в Cortex-M4 Technical Reference Manual Revision r0p1 все варианты и тайминги подробно расписаны.


Что ж вы такое придумываете, что вам и такта жалко, да и еще разогнать надо?

Во-первых, напряжение на камне у STM32F4 Discovery 3.0V. (внешние устройства - SD-карты, подсветку LCD - лучше запитывать отдельно, я использовал отдельный стаб, запитывая его от 5V с Discovery).
Это уже снижает разгон в сравнении с питанием 3.3V. Тем не менее и на трех вольтах он легко уходит за 200MHz, если изменить настройки PLL. Я запускал и на 260MHz. Но если нужна периферия, то самая большая частота не всегда самая оптимальная, например SPI LCD у меня работает примерно до 33MHz, а SDIO и FS USB требуют клок 48MHz, SD по SPI ограничена (в теории) до 25MHz. Так как системная частота увязана с SDIO и FS USB (при желании можно еще и с I2S связать), то пока оптимальный выбор для меня - 216MHz. Но поскольку камень новый и пока в процессе освоения, в основном работаю в номинале. Кстати, впервые пришлось на SPI использовать флаг BUSY, на Cortex-M3 обходился без него. Да и над FATFS пришлось надругаться, не хотела работать.


Так и надо читать папирус, пока время есть, и проходить сухой тренаж - скачай фреймворки, поковыряйся. На днях, кстати, в разделе Firmware на сайте ST появился родмап софта, там планы по всему спектру МК STM, много чего интересного обещано на Q1 2012.

Обновилась Atollic True Studio for STM32 Lite до версии 2.3. В числе улучшений - переработанная поддержка вычислений с плавающей точкой. Теперь для таких операций доступна опция "HW implementation", ранее были только "SW" и "Mix HW/SW". Перепрошел тесты, описанные на предыдущей странице, результат впечатляет - стало быстрее, более, чем в три раза!
Теперь цикл из вычисления 10 млн. дистанций на плоскости плюс пару арифметических операций выполняется за 1467 мс (HW) против 4585 мс (Mix HW/SW) и 45159 мс (SW). То-то я никак ранее не мог понять - по подсчетам циклов выходило, что результаты должны быть как минимум в 2 раза лучше.
Но развертка цикла из 10млн операций на 1 млн с 10 проходами в цикле опять приводит к тому, что, как и прежде, в каждом проходе только первая операция вычисления квадратного корня выполняется аппаратно, следующие 9 - программно. Итоговое время - 7469 мс. Где-то они опять чего-то просмотрели.

Для Discovery теперь автоматически подгружается библиотека с поддержкой установленного аудиокодека и акселерометра, исправлена и загрузка правильных значений PLL. Но по-прежнему не удосужились добавить переменную окружения с правильной частотой HSE_VALUE, надо ставить самим или редактировать файл stm32f4xx.h.

Помимо получения стереокартинки, контроллер еще специальной обработкой нагрузить хочу
Вот, собственно, начало проекта:
#77
В деталях, с удовольствием, расскажу, когда алгоритмы на реальном "железе" проверю.

Питание, похоже да, у Дискавери не очень, преобразователь отдельный поставил:
#77


Если за 200 Мгц уходит - отлично! При меньших частотах 640х480 от 2-х камер обработать в реальном времени - нет шансов даже в теории.

На счет чтения байтов - думаю, как алгоритмы оптимизировать.
У Cortex-M4 в ассемблере нет команды, чтобы, например, сложить 1-ый и 3-й байты, расположенные в одном регистре т. е. [0..7] и [16..23]?
Из нескольких команд: пересылка + сдвиг + И + сложение, 4 операции получается. Побайтно читать - тоже не выход, дольше будет.

ARM-овский ассемблер еще только изучаю - интересный он оказывается! Со времен ZX не кодил на низком уровне.
Заметил, с изучением микроконтроллеров вернулось ощущение программистской романтики 48Килобайт

Начнем с того, что понятие "реального времени" - это работа в расчетном проектном режиме. Абстрактного "реального времени" нет в природе, то есть, грубо говоря это такое время отклика, на которое вы свою систему проектируете.
Судя по всему, вы на DCMI будете поочередно давать данные (байты? BW? RGB? YUV?) с камер. Надеюсь, вы почитали, какие форматы поддерживаются.
Смею предположить, что это система машинного зрения. Вообще-то канал DCMI в 54MBytes/s при номинале МК в 168MHz представляется достаточным для двойного VGA. Просто надо подумать, как лучше подавать интерлив (или даже оба параллельно на 14 битной шине).

И потом, DCMI работает только с DMA, вам ведь все равно полученный фрейм-буфер (на кадр, строку или несколько строк) дербанить придется.

В любом случае, вы смотрите не на обычные команды ассемблера, а на те, что отличают Cortex-M4 от прочих Cortex-Mх - это ведь DSP процессор, у него есть масса SIMD инструкций, выполняемых за один такт (и инлайновый враппер всех ассемблерных DSP-команд для C).

Спасибо огромное за все рекомендации! Ценно и по делу.


Скорее, получится мое представление о такой системе Даже не машинное зрение, а интеллектуальный датчик препятствий, малопотребляющий и без внешней обработки данных на большой x86 машине.
Бинокулярные кадры позволят получить ту информацию об объектах, которую из плоской проекции извлечь сложно.
Если удастся кадров 15 в секунду обрабатывать - уже неплохо будет - "реальное время", так сказать.

Камеры OV7670 - самые доступные на Ибее.
Формат удобнее YUV. Камера дает Y-Cr-Y-Cb, яркости отдельно, цвета отдельно и чередуются. Получается экономия ресурсов: для выделения контуров с яркостью работаю, а цвет можно обрабатывать при необходимости только в значимых областях.

По подключению 2-х камер к 1 DCMI есть сложности. У STM32F407VGT6 максимальная разрядность DCMI урезана до 12 bit, если я правильно даташит понял. Приятно получать данные параллельно, но по 2 младших разряда уйдут, хватит ли точности - надо смотреть на практике.

Скачал с сайта ARM чудесный документ "Cortex-M4 Devices Generic User Guide". Система команд M4-го расписана во всей красе. Изучаю. Если нужен, пришлю, т. к. на их сайте искать доки не всегда быстро выходит

И очень насущный вопрос - среда разработки и прочий софт под Cortex.
Как я понял, привычный GCC+Eclips - далеко не лучший вариант.
Какой Вы софт используете? Буду благодарен любым советам и рекомендациям.

Вообще-то IDE - это дело вкуса, лично для меня так GCC + Eclipse лучший. Другое дело полноценность и цена.
Навскидку (могу что-то упустить).

Из бесплатного для STM32F4.
Можно пойти по пути YAGARTO, но это не для слабонервных.
CooCox, но поддержка M4 обещана в течение Q1, пока только M3 и ниже.
IAR и Keil предлагают бесплатные стартовые версии с возможностью компиляции кода до 32К и без права коммерческого использования.
Atollic Lite, на базе GCC + Eclipse, без ограничения на размер и коммерческое использование, но в IDE несколько пакостных ограничений. Хотя некоторые можно легально обойти (не имеется в виду левая установка проф версии). Атолликом я и пользуюсь.

Из платного за небольшие деньги - Raisonance Ride 7. Нужно купить их дебаггер (ок. 100 евро за std версию с ограничением по отладке 64K, для заливки ограничений нет), через год и далее ежегодно надо будет емнип по 40 евро платить. Их флэшер (программа для прошивки) мне нравится больше всех подобных софтин. Поддерживается широкий спектр МК.
Чуть дороже Crossworks от Rowley Associates, ну а остальные с ценником >800 баксов ( IAR, Keil, Atollic, Code Red, Green Hills etc). Это задорого, а крякнутыми программами не пользуюсь.

Прекрасно, Atollic Lite то, что надо.
Легальный софт всегда приятно использовать. В принципе, для хобби 100 евро не жалко потратить (800 - жалко ), но сейчас главное начать.

Глянул, что за ограничения у Лайта. Все же не очень хорошо: отсутствует поддержка языка С++ (только Си и ассемблер). А где почитать про "легально обойти"?

Нигде, наверное, нужно самому пощупать "и опыт, сын ошибок трудных" (с).
Из намеренно введенных пакостей - можно установить только один брейкпойнт для отладки.

Я обхожу так - определяем заглушку (можно ввести и параметры для прсмотра чего-нибудь, если надо):

на строку с __NOP() ставим наш единственный брейкпойнт.


И в программе, везде, где надо брейкнуть, вставляем конструкцию




SW_BREAKPOINT отключает эту хрень для релизной компиляции.

Немного громоздко, но зато везде, где надо, будет останов.

Еще одна крупная жадность атоллика - запрет перенаправлений стандартного ввода-вывода, все семейство функций printf и подобных линкуется на пустышки. Т.е. даже свою putchar нужно переименовывать, к примеру, на putchar2. И надо использовать свою функцию форматированного вывода, я взял готовую навроде этой. И сделать свой перенаправляльщик.

Еще они зажали статистику по скомпиленному исполняемому файлу, нет листинга, только маппировка, и еще всякой хрени много, да и хрен с ней.

Проблема, при которой аппаратное извлечение квадратного корня в программе, скомпиленной в Atollic True Studio выполняется только раз, сменяясь на програамную заготовку из рантайм библиотеки, не давала покоя.
Решил посмотреть на флаги FPU регистра FPSCR. Оказывается, после первого вычисления корня взводится флаг события IOE (Invalid Operation Event). При этом сам корень вычисляется правильно.
Я, грешным делом, подумал, может это сделано специально, дабы замедлить работу бесплатной версии в сравнении с проф (обработка этих флагов возможнеа только в priveleged mode), но все же вчерась написал о проблеме в саппорт. Так как бесплатная версия саппортом не поддерживается, то, если это действительно введено намеренно, ответа не будет.
Однако же, мы вступили в переписку и им со второго раза удалось воспроизвести проблему. Стало быть, это баг чистой воды.

Пока предложено добавить в строку компилятора опцию -fno-math-errno. Постоянное решение будет попозже.
Вот цитата из последнего сообщения саппорта в нашей переписке: "I can't say when we will fix this, but we will definately look more at this."

С опцией -fno-math-errno развернутый цикл выполняется за 1075мс, т.е. почти на треть быстрее неразвернутого, что и хотелось получить изначально.

Спасибо, zauropod, за рекомендации, пробую теперь разный софт.
Говорят Кейл хорош из-за симулятора контроллеров. Скачал пробную версию (32К ограничение), полноценной поддержки STM32F407VG симулятором нету. Долго искал... оказалось, даже в дебрях сайта Кейла написано - не поддерживает. Есть поддержка абстрактного Cortex-M4, в принципе, уже хорошо - можно посмотреть работу DSP, но как-то маловато, хотелось реальные тайминги оценить и работу DCMI.
Да, и пока запустил отладку в симуляторе - чуть не забросил Кейла, без магических настроек ini-файла под STM32F407VG, отладчик сыпал ошибки - день убил на выяснение, что не так.
От столь дорогого продукта (цена 100-200тыс. р. за полную версию) ожидал большего, как минимум хорошей работы "из коробки". Может я его просто "готовить" не умею?
А так Кейл - нормальная система. IDE приятная, на уровне Эклипса; компилит быстро, качество генерируемого кода еще не смотрел. Но цена полной версии шансов обосноваться в моей системе не оставляет. Хотя, может Кейловский C++ компилятор супер-оптимальный код генерирует?
Пока в предпочтениях лидирует Atollic.

1. Не подскажете ли, где полноценный симулятор STM32F407VG есть?
2. Еще вопрос, проводились исследования оптимизации разных компиляторов? Кейл и GCC сравнить?

Так обратите внимание на первоисточник. Сама компания ARM все делает. Их есть у нее - The ARM Development Studio 5 (DS5). Да и не только - но это все дорогостоящие вещи. Есть, правда, "free community edition DS5", ноя не в курсе как у нее.
Проф Атоллик симулирует только базовый набор инструкций-памяти, без периферии, DMA, etc.


Наверняка где-то такая инфа есть, но мне она неинтересна. Я попробовал Атоллик, меня он в целом устраивает, нюансы по оптимизации меня на данном этапе не волнуют. Keil никогда не пользовал, когда-то совсем не зацепил. Так что тут ничего не подскажу.

Вот спасибо! Про средства самой ARM и не подумал. Сижу, мучаюсь.
Как здорово, когда есть старший опытный товарищ

Zauropod че не пишешь про своего монстра. Хорошо Neo333 разбавил твою тему с 3D.
Почитал про ov7670 хороша штучка, понравилось полное описание реистров управления чипа.
Какие глазки планируешь использовать, поделись плиз информацией.
В мечтах тоже киборга заиметь. И еще вопросик если смысл фокусировки, как я понимаю она
должна управлятся програмно, автофокус не пойдет. У ov7670 про фокус не чего не написано.

Добавлено спустя 1 час 37 минут 20 секунд:

Наверно лучше задействовать два ST32F4, каждый на свою камеру (с обменом между собой),
а еще круче подыскать двухядерный МК c двумя интерфейсами, если появились в природе.
Будет прям как у хомосапиансев.

Есть такие. У TI, например, видел. Весьма серьезные решения, дорогие и сложные в разработке и программировании. Как правило, в BGA и требующие сложную обвязку.
В пром. применении бинокулярное зрение используется давно, решения, естественно, отработаны.
Для себя проще какой-нибудь BeagleBoard XM (Cortex-A9 1000Mhz) с двумя USB WEB-камерами под Линуксом запрограммировать, если нужно стерео-видео и нет желания сильно вникать. Скомпилировать OpenCV библиотеки и готово - создавай робота с двумя рабочими глазками

Но, для меня, задача именно в том, чтоб не плодить сущности без надобности, а добиться от копеечных (почти) деталей, собранных "на коленке", максимального результата.
Отточить алгоритмы, чтоб без всяких OpenCV и многоядерных процев получить достойный результат на маленьком контроллере. До выхода STM32F4 теоретический рассчет показывал - не возможно, даже на Cortex-M3 с разгоном.
На Cortex-M4 возможно, хотя и на грани. Решить задачу с жесткой оптимизацией по таймингам - удовольствие.



С фокусировкой все сложно и просто одновременно. Как правило, фокус жестко настроен от, примерно, 1 метра и до бесконечности, т.е. про него можно не думать - это просто, но четкость будет не всегда.
Если надо автофокус - здесь все сложно и дорого. Дома сделать автофокусный объектив... примерно как пол-фирмы Кэнон создать Есть в продаже готовые решения оптики с фокусировкой, но ЦЕНА...

neo333
Я в матиматике слаб, но всетаки осмеюсь повторно предлажить два ST32F4. Учитывая, что пишете на си потом проще будет
скомпелировать на дешевый двухдерный МК (китай нам поможет)

Соласен, если с 1 чипом не выйдет, попробую два. Даже заказал еще 2 Дискавери, благо не слишком дорогие. Контроллеры отдельно - купить, примерно столько же выходит.
Однако, если получится реализовать задуманное на 1 чипе, это будет победа!

Сложность подключения к 1 stm32F407VG - это 16 линий данных с 2-х камер на, всего, 12 линий данных DCMI у контроллера. Придется младшие (или старшие?) биты данных обрезать. Остальное, вроде, решается.
Для моей задачи пожертвовать 2 битами можно. Картинка грубее будет, но контрастные участки распознаваться будут.

Коллега, max0000000, поделитесь о своем проекте, робот продвигается? Правда, интересно кто что делает? Такие описания поддерживают интерес к хобби, потому и сам делюсь.
Zauropod, умничка, статьи пишет. Большое дело - такая информация для увлеченных людей.

Так там конь так и не валялся. Ничего и не стал паять на сделанных платах, в том числе и видеокамеры. Сначала ждал STM32F2 (не хотелось делать на старом 926-ом атмеловским арме AT91). Но их долго не было, в общем, перегорел. Да и со здоровьем не очень.

А что ты имеешь против 3Д?
Две камеры, кстати, это также есть 3D.

Да хватит там и одного.
Кстати, камеры можно попробовать подключить не к DCMI, а по FSMC, так как адрес не нужен (только для формирования сигнала выборки кристалла), а к 16-битной шине подсунуть обе камеры, на Dicovery это можно попробовать реализовать.

Да я вот за осень несколько проектов нарисовал - по подключению к МК ,имеющем контроллер памяти, видеоконтроллеров под RGB монитор (у Epson eсть интересные модели, в том числе и с аппаратным кодированием-декодированием JPEG), выход на VGA, HDMI. Плюс платку на базе Freescale imx233 под гаджет. Всю элементную базу давно уже купил на эти дела. Но вот чего-то духу не хватило отдать платы на изготовление, а тут как раз STM32F4 подоспел. Надо под него сделать плату, с памятью и прочими чудесами, но вот пока руки не дошли, как нарисую плату под STM32F4, так все сразу и отдам на изготовление. И платки для попробовать новинки - силиконовский радиочип, MRAM SPI память и т.д.


Давно уже ничего не публиковал. Сейчас вот решил сделать программный декодер JPEG для STM32F4, если будет все удачно - напишу, наверное. Можно, конечно, написать еще про свой новый генератор-редактор шрифтов и соответствующие процедуры вывода (безотносительно к типу МК, в шрифтах используется свой формат хранения с кодированием битовых полей переменной длины, но пока без Хаффманского сжатия).

Пока только в голове. Еще даже не определился на какой ход его ставить либо гусеницы либо
дирежабль. Как опредилюсь буду искать китайскую игрушку и выкидывать всю электронику.
Мозги конечно ST32F4, камера одна (две если только с вашей с Zauropod помощью, математику
один не потену) растояния до препядствий с помощью лазера.

Конкретно щяс пытаюсь скрестить феритовое кольцо с XPLAIN+LS020 (сварочный полуавтомат)


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

Доброго дня, коллеги.
Появилась надобность визуализировать результаты работы контроллера. Стоит без дела старый LCD монитор - подумал, надо задействовать.
Решил, возьму STM-ку "пожирнее" и софтово видеоконтроллер реализую + VGA выход на резисторном ЦАП-е. В теории, формирование картинки 800 х 600 старшие модели вытянут - надо выдавать в порт данные со скоростью 40МГц. Память для видеобуфера - SRAM, и через FSMC взаимодействовать. В реальности же все оказалось печально. Углубился в даташит, оказалось FSMC по ДМА забирает данные из памяти ну о-о-очень медленно. Тактов 8 уходит на цикл.
Выходит, сколько нибудь приличный видео-контроллер из STM32 не сделать.
Надо специальный чип ставить.



Расскажите, пожалуйста, подробнее о проекте. Что за контроллер Epson? Где найти в продаже? Посмотрел на сайте Epson, там не нашел чипов с поддержкой VGA и HDMI.