Comments 50
Ваш цикл (я надеюсь!) статей очень кстати. Я вчера почти весь день убил, пытаясь собрать хоть в чём-нибудь код, сгенерированный STMCube. Первый свой проект я делал в Eclipse + GNU ARM Plugin, но собрать это в нём — без шансов. В итоге установил IAR и там собрал и даже запустил, хоть и не без проклятий и ещё часа гугления.
В какой IDE вы разрабатываете, что пореуомендуете?
В какой IDE вы разрабатываете, что пореуомендуете?
Я не хотел бы обсуждать здесь IDE, чтобы не вызывать холиваров, и не пропагандировать установку нелицензионного ПО.
Но могу сказать, что вы на верном пути.
Но могу сказать, что вы на верном пути.
Что бы собрать какой-то проект для stm32 (в том числе и сгенерированный STMCube) не требуется вообще никакая IDE. Нужен исключительно компилятор C/C++ для ARM (например gcc) и всё. Ну и драйверы ST-Link/V2 (с сайта ST) для собственно прошивки полученного бинарника в МК. Для удобного управления данным процессом обычно ещё используют какую-то современную систему сборки (CMake/GYP/scons/waf и т.п.), но это исключительно для удобства, а не обязательное требование — для первоначальной сборки достаточно просто командной строки.
А IDE — это для удобства навигации по коду, автодополнения, рефакторинга и т.п. удобств в написание кода, а не для сборки готовых исходников.
А IDE — это для удобства навигации по коду, автодополнения, рефакторинга и т.п. удобств в написание кода, а не для сборки готовых исходников.
Ну, да, кроме как просто собрать скелет, я хотел бы ещё какую-то свою функциональность дописать :)
И даже отладить.
И даже отладить.
Именно. Навигация пр коду, это хорошо, но проекты для микроконтроллеров редко бывают огромными. А вот интерактивная отладка очень нужна.
Кстати, а вот насчёт отладки есть интересный нюанс, т.к. в мире МК основные затруднения возникают скорее в режиме реального времени и соответственно плохо отлаживаемы в классических пошаговых режимах (т.е. сама то отладка без проблем реализуется, только смысла от неё нет, т.к. все тайминги всех протоколов нарушаются). И соответственно тут больше помогает осциллограф плюс например такой интересный инструмент как STMStudio (так же как и драйверы для st-link/v2 бесплатно качается с сайта ST).
Ну лично я бы мог порекомендовать QtCreator в роли C++ IDE. Но в целом подходит вообще любая, и Eclipse и VisualStudio и Netbeans и CLion…
Надо будет попробовать QtCreator, пока это самая правильная IDE, которую я видел.
Я бы тоже мог порекомендовать Qt Creator и билд-систему qmake для десктопных С++ проектов (и Qt проектов для Android / iOS). Как его использовать для STM — ума не приложу, если я даже в Eclipse c GNU ARM плагином не смог собрать код, сгенерированный STMCube. И в EmBitz не смог (который бывший EmBlocks — embedded IDE на базе Code::Blocks).
Ну вообще то qmake — это достаточно убогая система на фоне современных решений. Но и её более чем достаточно для данных примитивных целей.
А в чём собственно затруднение? Сборка под МК на базе ARM ничем не отличается от сборки обычного десктопного приложения с помощью gcc. Вся разница исключительно в нескольких дополнительных опциях компилятора (и то они в основном для экономии памяти) и одной опции компоновщика.
Кстати, а опции самого STMCube стоят правильно? ) Там есть существенные различие в настройка генерации. Причём разница не только в формате проектов целевых IDE, но и в режиме формирования каталогов исходников (добавлять библиотечные файлы или нет и т.п.).
А в чём собственно затруднение? Сборка под МК на базе ARM ничем не отличается от сборки обычного десктопного приложения с помощью gcc. Вся разница исключительно в нескольких дополнительных опциях компилятора (и то они в основном для экономии памяти) и одной опции компоновщика.
Кстати, а опции самого STMCube стоят правильно? ) Там есть существенные различие в настройка генерации. Причём разница не только в формате проектов целевых IDE, но и в режиме формирования каталогов исходников (добавлять библиотечные файлы или нет и т.п.).
Не трогал опции Cube, ничего о них не знаю.
Главная проблема со сборкой — как-раз таки в бибилиотеках, peripheral library, HAL и всей этой ерунде.
Главная проблема со сборкой — как-раз таки в бибилиотеках, peripheral library, HAL и всей этой ерунде.
Там вообще много разных интересных настроек по генерации исходников. Но для конфигурации дальнейшей сборки принципиальны только две:
1. Целевая IDE для которой генерируется проект. И хотя сам сгенерированный проект (в смысле файлы настроек IDE) мы не используем вообще, но от этой настройки зависит и создаваемая структура проекта. Лучше всего ставить SW4STM32 — будет меньше всякого мусора и будет всё нужное для gcc.
2. Как раз используемые библиотеки. Там есть варианты: добавить сами библиотеки, добавить в проект только нужные файлы из них, добавить ссылки на них (в смысле только #include и прописанные пути к библиотекам в настройках проекта). Соответственно для разовой сборки лучше всего ставить второй вариант, тогда просто в папке проекта будет всё нужное для сборки. Ну а лично у меня все библиотеки (HAL и т.п.) уже заранее собраны и настроены отдельно, так что я всегда использую 3-ий вариант.
1. Целевая IDE для которой генерируется проект. И хотя сам сгенерированный проект (в смысле файлы настроек IDE) мы не используем вообще, но от этой настройки зависит и создаваемая структура проекта. Лучше всего ставить SW4STM32 — будет меньше всякого мусора и будет всё нужное для gcc.
2. Как раз используемые библиотеки. Там есть варианты: добавить сами библиотеки, добавить в проект только нужные файлы из них, добавить ссылки на них (в смысле только #include и прописанные пути к библиотекам в настройках проекта). Соответственно для разовой сборки лучше всего ставить второй вариант, тогда просто в папке проекта будет всё нужное для сборки. Ну а лично у меня все библиотеки (HAL и т.п.) уже заранее собраны и настроены отдельно, так что я всегда использую 3-ий вариант.
Спасибо. У меня тоже используется вариант «скопировать только нужные файлы», но это мне не слишком помогло (пока не поставил IAR, в которой можно просто открыть проект. И то, там не все нужные настройки были прописаны, но гугл помог — теперь всё собирается, работает и даже дебажится).
С точки зрения оптимизации кода(и по скорости и по размеру) компили IAR и Keil показывают существенно лучшие результаты, нежели SW4STM32. Только есть два но:
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.
А есть какие-то сравнения на предмет размера кода и скорости? Я не для холивара, а интереса ради; как я понимаю, у SW4STM32 под капотом gnu toolchain — там много что можно подкрутить в случае необходимости.
Если говорить про компиляторы (а не про IDE, хотя у вас тут озвучены они, но на самом деле они ни при чём), то возможно указанные продукты и генерируют изредка чуть более оптимизированный под конкретный МК код в сравнение с gcc. Но при этом это полностью нивелируется отвратительной поддержкой современного стандарта языка (я про C++14 и т.д.), которая не позволяет писать современный быстрый и одновременно красивый код.
Для того, чтобы сделать (а не «собрать») и сдать заказчику проект без IDE, приспособленной для STM32 в обойтись невозможно.
С помощью CubeMX генерируем проект для IDE SW4STM32, затем, с помощью https://github.com/baoshi/CubeMX2Makefile творим магию
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. Там можно выбрать конкретную плату и сразу получить проинициализированную периферию именно для этой платы.
BGA монстр из серии F7 в роли мигателя светодиодами — это конечно весьма забавно. Но мне кажется что здесь в качестве примера лучше подошло бы что-нибудь из серии F0 в корпусе TSSOP20 — как-то адекватнее и по цене и по сложности и по мощности.
Сам увлекся программированием для микроконтроллеров, посмотрел на суммарное количество инструментов для OSX и понял что нужно писать свою среду разработки. В качестве встроенного инструмента планирую в следующей внедрить аналогичный генератор себе. Кому интересно, может погуглить Stm32Box.
Как Вы вовремя! Вчера вечер потратил на выбор микроконтроллера с низким потреблением и размышления на тему «пора переходить на ARM». Буду должен.
Есть возможность использовать Sublime Text 2 как более-менее нормальную IDE для STM32 (отладка, прошивка, запуск CubeMX прямо из редактора). Для себя собирал seed-проект под эту тематику. Нужно будет посмотреть, обновили ли ключевые плагины под ST3, да пересобрать всё это под него.
Будет ли интересна статья на эту тему? Просто она, фактически, будет адаптацией уже существующих статей к текущим реалиям (если сборка такого проекта сейчас вообще возможна, зависит от плагинов).
Будет ли интересна статья на эту тему? Просто она, фактически, будет адаптацией уже существующих статей к текущим реалиям (если сборка такого проекта сейчас вообще возможна, зависит от плагинов).
Nucleo тоже вполне не плохи вроде. Хотя возможно я чего и не понимаю.
Для удобной работы и компиляции в GCC под Windows (я использую в качестве редактора Visual Studio Code в качестве редактора) рекомендую:
1. Использовать CubeMX2Makefile (уже говорили ниже). В ReadMe там приведена ссылка на набор файлов (make, cp, rm, etc), Python 2.7 (для запуска скрипта конвертации)
2. После клонирования я создал файл createmake.cmd с содержимым:
Он позволяет запускать createmake из папки проекта и формировать там makefile.
3. В файл CubeMX2Makefile.py я добавил строки перед Clean
Они позволяют заливать прошивку с использованием ST-Util
4. Соответственно в PATH прописаны пути к GCC, CubeMX2Makefile, утилитам Make (etc), Python.
5. Теперь после генерации проекта в CubeMX я просто открываю проект в VSCode, открываю консоль и выполняю команды: createmake (создание Makefile), make(сборка проекта), make flash (заливка проекта)
Отдельно хочу рекомендовать STM-STUDIO-STM32 — отладчик от ST Microelectronics. Собрав проект, в отладчике можно открыть из папки build elf-файл, иипортировать из него переменные и отлаживать их в реальном времени.
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-файл, иипортировать из него переменные и отлаживать их в реальном времени.
1) Очень рад, что на хабре появляются такие статьи по современным библиотекам, полгода назад мне их очень не хватало, когда переходил с avr и pic на STM32.
2) С точки зрения курса «STM32 с нуля» — данная отладка совсем не лучший вариант. Объясняю, почему: другая архитектура относительно ядер Cortex M4,M3,M0(+) — Кэш данных, кэш команд, 64-бит шина данных, суперскалярность, ветвление в 1 такт.
Данный процессор — мощный агрегат для ЦОС, и содержимое отладки как бы намекает: микрофоны с PDM-сигналом на выходе, требующим цифровой фильтрации, интерфейс для подключения видеокамеры, жирный дисплей с сенсором. Все это добро требует нехилых вычислительных мощностей на обработку, и без хорошего понимания математических основ ЦОС даже этот контроллер не сможет выполнять свои функции полноценно, так-что этот камень не претендует на нишу «STM32 с нуля» совсем.
Для начала лучше всего пойдет любая отладка на ядре Cortex M3/M4, с небольшим количеством внешней периферии(светодиоды, кнопочки, датчики ускорения/углового ускорения, например), но с большими гребенками и выведением всех свободных выводов на них, где каждый из выводов можно пощупать тестером или осциллографом.
Там и все интерфейсы связи доступны, и микроконтроллеры вписываются в общую концепцию.
Так, например, держа в уме отличия Cortex M0 и M4, можно без проблем писать код и на то и на другое ядро, и даже ожидать соизмеримой производительности (с точностью до DSP инструкций и некоторых других нюансов, в среднестатистических проектах разница в скорости выполнения одной и той же программы там и там — порядка 10-15 %, а скорость обмена данными по интерфейсам связи так вовсе не отличается при равной тактовой).
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 очень годный вариант, и стоит вдвое дешевле, чем эта плата.
А код можно писать, вообще ничего не зная об ядре, просто на С.
Во-первых, я пишу цикл статей не про архитектуру 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 микросекунды. Устраивает вас такое время обработки прерывания? Если да — пожалуйста, не нужно разбираться в ядре, в регистрах и библиотеках.
Моё мнение в том, что 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. Но это уже совсем другой уровень, и по сложности, и по стоимости.
Как правило, для большинства практических задач, нет необходимости считать такты до такой степени. Разве что оптимизировать прошивку под обработку сигналов. Но здесь опять же, такая оптимизация имеет практический смысл только для очень небольшого диапазона задач, где сигналы достаточно высокочастотные, или обработка достаточно сложна, чтобы контроллер не справлялся без оптимизации, и в то же время, достаточно низкочастотные, чтобы он вообще справлялся. Для реальных задач обработки сигналов в real-time нужны FPGA, и они есть, в том числе и с встроенными ядрами ARM. Но это уже совсем другой уровень, и по сложности, и по стоимости.
Конечно, Вы правы, что для вхождения не нужны такие дебри. Однако, было бы огромным плюсом Вам и всем читающим, сделать спойлер «а теперь сделаем <по-взрослому>», где Вы перерабатываете код и говорите об избыточности HALa.
Польза от этого очевидна: уменьшение количества тактов на выполнении кода позволит не только повысить производительность, это позволит уменьшить энергопотребление(!), что так модно в век wearable и IoT
Польза от этого очевидна: уменьшение количества тактов на выполнении кода позволит не только повысить производительность, это позволит уменьшить энергопотребление(!), что так модно в век wearable и IoT
Это было бы полезно, но как-нибудь в другой раз.
Пока я хочу привести несколько примеров использования различной периферии.
Пока я хочу привести несколько примеров использования различной периферии.
Простите что вмешиваюсь, но так ли очевидна польза? Из практики, HAL не так уж часто стоит на каких-то критических путях выполнения, где он делает большой вклад в общую производительность или задержки, и эти пути вполне можно оптимально переписать руками, HAL не настолько толстый сам по себе. Да и в контексте IoT о производительности не всегда приходится говорить — многие устройства всю жизнь спят, им всё равно, что в остальном коде творится. Избавившись же от HAL, вы потеряете полезный слой абстракции, который облегчал вам разработку.
Лично я купил эту плату не столько из-за ядра или возможностей ЦОС, сколько из-за Ethernet, USB и, главное, отличного дисплея с емкостным сенсором.
Ну вот ethernet — это действительно привилегия мощных МК (начиная с F4) и если он реально нужен, то выбор конечно же оправдан (но опять же это будет не самый стандартный расклад для мира МК). Что касается всех остальных упоминаемых в статье и комментариях возможностей (таймеры, dac, usb, тачпадов и т.п.), то поддержка подобного имеется начиная с самой младшей (F0) серии.
Sign up to leave a comment.
Начинаем работать в STM32CubeMX. Часть 1