Комментарии 50
В какой IDE вы разрабатываете, что пореуомендуете?
Но могу сказать, что вы на верном пути.
А IDE — это для удобства навигации по коду, автодополнения, рефакторинга и т.п. удобств в написание кода, а не для сборки готовых исходников.
И даже отладить.
А в чём собственно затруднение? Сборка под МК на базе ARM ничем не отличается от сборки обычного десктопного приложения с помощью gcc. Вся разница исключительно в нескольких дополнительных опциях компилятора (и то они в основном для экономии памяти) и одной опции компоновщика.
Кстати, а опции самого STMCube стоят правильно? ) Там есть существенные различие в настройка генерации. Причём разница не только в формате проектов целевых IDE, но и в режиме формирования каталогов исходников (добавлять библиотечные файлы или нет и т.п.).
Главная проблема со сборкой — как-раз таки в бибилиотеках, peripheral library, HAL и всей этой ерунде.
1. Целевая IDE для которой генерируется проект. И хотя сам сгенерированный проект (в смысле файлы настроек IDE) мы не используем вообще, но от этой настройки зависит и создаваемая структура проекта. Лучше всего ставить SW4STM32 — будет меньше всякого мусора и будет всё нужное для gcc.
2. Как раз используемые библиотеки. Там есть варианты: добавить сами библиотеки, добавить в проект только нужные файлы из них, добавить ссылки на них (в смысле только #include и прописанные пути к библиотекам в настройках проекта). Соответственно для разовой сборки лучше всего ставить второй вариант, тогда просто в папке проекта будет всё нужное для сборки. Ну а лично у меня все библиотеки (HAL и т.п.) уже заранее собраны и настроены отдельно, так что я всегда использую 3-ий вариант.
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.
А есть какие-то сравнения на предмет размера кода и скорости? Я не для холивара, а интереса ради; как я понимаю, у SW4STM32 под капотом gnu toolchain — там много что можно подкрутить в случае необходимости.
cubemximporter.py eclipse_project_folder cubemx_project_folder
Здорово, сейчас как раз пытаюсь привести к виду, в котором не стыдно выложить, то же самое для CMake.
С какой целью, если не секрет? Мне это нужно из-за острого желания прикрутить CLion(очень уж нравятся продукты Jetbrains), который использует CMake и пока что не признаёт альтернатив. Делал на основе CMake-скрипта из туториала на их сайте.
В том генераторе, кстати, есть мелкая ошибка, зарепортил.
А вы хотите именно с интеграцией STM32CubeMX? CLion для STM32x вполне можно использовать, очень комфортно, но Cube интегрировать порывов не было — во-первых, у него на момент рассмотрения были нелады с Linux, а во-вторых, делать инициализацию руками как-то гибче.
Я просто с Cube начинал, так что вопрос привычки, насчёт гибче — не знаю даже, поделитесь примерами, где он не справлялся? Так-то я и руками могу, оно и кошернее, но Cube нравится за наглядность, особенно в распиновке и настройке тактовых частот. Насчёт неладов: это упакованное Java-приложение, на просторах сети есть мануалы по запуску в Linux, проверял лично — работает.
Дело давно было, Cube тогда ещё был сырой — тогда пробовал, но у него ещё был капризный .exe внутри, с тех пор, видимо, далеко шагнул. Мой сценарий — затяжные проекты с несколькими целевыми платформами (разные ревизии железа, разные распиновки, периферия), настройка тактовых частот и источников тоже меняется в процессе работы, периферия включается когда нужно, что-то отключается в энергосберегающих режимах — сгенерированные куски при таком раскладе уже не так полезны. Плюс иногда попадаются баги в HAL, совсем не лезть куда-то руками не получается (в последнем на момент написания инициализация WWDG сломана, например). Но, да, не очень распространённый use case, так что я от Cube не отговариваю, мне просто интересно было.
Скажу сразу, STM32CubeMX существует только в Windows-версии. Пишут, что нормально работает под wine, я лично не пробовал.
Он существует и в linux и даже в os x версии. Это «обычное» java-приложение.
hint: в new project есть board selector. Там можно выбрать конкретную плату и сразу получить проинициализированную периферию именно для этой платы.
Будет ли интересна статья на эту тему? Просто она, фактически, будет адаптацией уже существующих статей к текущим реалиям (если сборка такого проекта сейчас вообще возможна, зависит от плагинов).
1. Использовать CubeMX2Makefile (уже говорили ниже). В ReadMe там приведена ссылка на набор файлов (make, cp, rm, etc), Python 2.7 (для запуска скрипта конвертации)
2. После клонирования я создал файл createmake.cmd с содержимым:
@ECHO OFF
IF "%1"=="" GOTO CURRENT
python %~dp0\CubeMX2Makefile.py %1
GOTO DONE
:CURRENT
python %~dp0\CubeMX2Makefile.py ./
:DONE
Он позволяет запускать createmake из папки проекта и формировать там makefile.
3. В файл CubeMX2Makefile.py я добавил строки перед Clean
#######################################
# flash use ST-Link
#######################################
flash:
st-link_cli -P $$(BUILD_DIR)/$$(TARGET).bin 0x08000000 -Rst
Они позволяют заливать прошивку с использованием ST-Util
4. Соответственно в PATH прописаны пути к GCC, CubeMX2Makefile, утилитам Make (etc), Python.
5. Теперь после генерации проекта в CubeMX я просто открываю проект в VSCode, открываю консоль и выполняю команды: createmake (создание Makefile), make(сборка проекта), make flash (заливка проекта)
Отдельно хочу рекомендовать STM-STUDIO-STM32 — отладчик от ST Microelectronics. Собрав проект, в отладчике можно открыть из папки build elf-файл, иипортировать из него переменные и отлаживать их в реальном времени.
2) С точки зрения курса «STM32 с нуля» — данная отладка совсем не лучший вариант. Объясняю, почему: другая архитектура относительно ядер Cortex M4,M3,M0(+) — Кэш данных, кэш команд, 64-бит шина данных, суперскалярность, ветвление в 1 такт.
Данный процессор — мощный агрегат для ЦОС, и содержимое отладки как бы намекает: микрофоны с PDM-сигналом на выходе, требующим цифровой фильтрации, интерфейс для подключения видеокамеры, жирный дисплей с сенсором. Все это добро требует нехилых вычислительных мощностей на обработку, и без хорошего понимания математических основ ЦОС даже этот контроллер не сможет выполнять свои функции полноценно, так-что этот камень не претендует на нишу «STM32 с нуля» совсем.
Для начала лучше всего пойдет любая отладка на ядре Cortex M3/M4, с небольшим количеством внешней периферии(светодиоды, кнопочки, датчики ускорения/углового ускорения, например), но с большими гребенками и выведением всех свободных выводов на них, где каждый из выводов можно пощупать тестером или осциллографом.
Там и все интерфейсы связи доступны, и микроконтроллеры вписываются в общую концепцию.
Так, например, держа в уме отличия Cortex M0 и M4, можно без проблем писать код и на то и на другое ядро, и даже ожидать соизмеримой производительности (с точностью до DSP инструкций и некоторых других нюансов, в среднестатистических проектах разница в скорости выполнения одной и той же программы там и там — порядка 10-15 %, а скорость обмена данными по интерфейсам связи так вовсе не отличается при равной тактовой).
Во-первых, я пишу цикл статей не про архитектуру Cortex M7 и не про данную отладку. Я пишу про STM32CubeMX. Я сразу написал, что подойдёт практически любая отладка.
Лично я купил эту плату не столько из-за ядра или возможностей ЦОС, сколько из-за Ethernet, USB и, главное, отличного дисплея с емкостным сенсором.
Насчёт того, что пинов на гребенки нужно выводить побольше, согласен. Видел плату тоже на STM32F7, без дисплея, но с Ethernet+USB, и с большими гребенками выводов. Для DIY очень годный вариант, и стоит вдвое дешевле, чем эта плата.
А код можно писать, вообще ничего не зная об ядре, просто на С.
Моё мнение в том, что CubeMX — отличная утилита для «вхождения» в мир STM32. Но не альтернатива чтению даташитов и референс мануалов, а дополнение. Все-таки человек, пишущий код под микроконтроллер, худо бедно должен знать архитектуру контроллера, знать, как работает периферия, и иметь представление о том, какие регистры для чего нужны.
Например: работа с прерываниями.
В ядре Cortex M0 — вход и выход из прерывания по 16 тактов.
В ядре Cortex M0+ — по 15 соответственно, в ядре M3, 4 и 7 — по 12.
Но, взять, например, HAL-овский обработчик прерывания по таймеру.
Если в коллбэк прописать простой инкремент счетчика или установку флага, не залезая в библиотеку (а тем более в регистры), обработка данного прерывания вместе с исполнением пользовательского кода (элементарная операция) занимает более 120(!) тактов, и это на ядре Cortex M4. На M0 — больше 130.
Если залезть в обработчик ручками и просто убрать обработку непроисходящих событий (нас интересует только событие переполнения), то результат уже значительно лучше, порядка 50 тактов.
Если же работать напрямую с регистрами, то получим 27(±1 на джиттер) тактов.
12 тактов вход
считать, изменить, записать
12 тактов выход
Итак, 130 тактов на частоте 72 МГц (Не видел камней на CortexM0 с большей тактовой частотой) — почти 2 микросекунды. Устраивает вас такое время обработки прерывания? Если да — пожалуйста, не нужно разбираться в ядре, в регистрах и библиотеках.
Как правило, для большинства практических задач, нет необходимости считать такты до такой степени. Разве что оптимизировать прошивку под обработку сигналов. Но здесь опять же, такая оптимизация имеет практический смысл только для очень небольшого диапазона задач, где сигналы достаточно высокочастотные, или обработка достаточно сложна, чтобы контроллер не справлялся без оптимизации, и в то же время, достаточно низкочастотные, чтобы он вообще справлялся. Для реальных задач обработки сигналов в real-time нужны FPGA, и они есть, в том числе и с встроенными ядрами ARM. Но это уже совсем другой уровень, и по сложности, и по стоимости.
Польза от этого очевидна: уменьшение количества тактов на выполнении кода позволит не только повысить производительность, это позволит уменьшить энергопотребление(!), что так модно в век wearable и IoT
Пока я хочу привести несколько примеров использования различной периферии.
Простите что вмешиваюсь, но так ли очевидна польза? Из практики, HAL не так уж часто стоит на каких-то критических путях выполнения, где он делает большой вклад в общую производительность или задержки, и эти пути вполне можно оптимально переписать руками, HAL не настолько толстый сам по себе. Да и в контексте IoT о производительности не всегда приходится говорить — многие устройства всю жизнь спят, им всё равно, что в остальном коде творится. Избавившись же от HAL, вы потеряете полезный слой абстракции, который облегчал вам разработку.
Лично я купил эту плату не столько из-за ядра или возможностей ЦОС, сколько из-за Ethernet, USB и, главное, отличного дисплея с емкостным сенсором.
Ну вот ethernet — это действительно привилегия мощных МК (начиная с F4) и если он реально нужен, то выбор конечно же оправдан (но опять же это будет не самый стандартный расклад для мира МК). Что касается всех остальных упоминаемых в статье и комментариях возможностей (таймеры, dac, usb, тачпадов и т.п.), то поддержка подобного имеется начиная с самой младшей (F0) серии.
Начинаем работать в STM32CubeMX. Часть 1