Comments 57
Первый раз пробовал что-то написать под STM32 из под Keil. Очень быстро перелез на CLion (gcc + OpenOCD), т.к. Keil, как IDE, по ощущениям, отстает где-то на 10-15 лет. Удобный редактор с возможностью vim режима, быстрая и точная навигация по определениям, подстветка, продвинутое автоформатирование, подсказки вроде clang-tidy, рефакторинги, интеграция с git, даже темная тема и другие мелочи — всего этого в keil не хватает.
Предполагаю, что в нем есть какие-то свои фичи, которых нет в более универсальных IDE вроде CLion или VS Code, но пока не сталкивался (может они нужны на более сложных задачах, где CLion + gcc + OpenOCD + gdb не хватит, не знаю).
А есть где дока, как использовать такую связку?
https://www.jetbrains.com/help/clion/embedded-development.html
Есть более старая, но чуть более подробная статья из трех частей:
https://blog.jetbrains.com/clion/2016/06/clion-for-embedded-development/
От себя могу добавить, что, используя эту связку, можно без проблем писать на C++ 2a под STM32 (gcc последний 2019-q4).
Для этого мне понадобилось только сделать пару однострочников, которые переименовывают все .c файлы в .cpp и обратно (на время перегенерации проекта в Cube, если что-то меняю или просто мигрирую на новую версию).
Понадобилось только добавить немного static_cast'ов в нескольких местах (и не забывать откатывать изменения генератора cube на этих строчках через git), игнорировать несколько видов предупреждений (у меня получилось -Wall -Wno-register -Wno-write-strings -Wno-sign-compare -Wno-unknown-pragmas -fno-exceptions -Wno-psabi в CMAKE_CXX_FLAGS) и исключить код FreeRTOS из переименования в cpp (иначе планировщик перестает работать когда код FreeRTOS скомпилирован как C++).
Интересует китайский j-link. Просто решил попробовать stm, подыскиваю среду. Кто что советует. И ещё вопрос, как либы скомпилированные подключать? Есть библиотека STM32CRYPTOLIB, а как подключить не нашёл
При установке еще предлагает дрова stlink, jlink поставить.
Windows/Linux — полёт успешный
У меня слегка эгоистичный подход — использую "чистый" Eclipse для всего. Проще довесить требуемые целевой архитектурой плагины чем перепревыкать. Да, STM32CubeMX есть плагином под эклипс. И работает, единственный минус — под linux надо указывать gtk=2.
В общем, свободная IDE гораздо лучше всякой проприетарщины!
Тут ведь дело не только в работе с кодом — нормальный дебаг, отображение состояния переферии, трассировка значений переменных — вот это все можно добавить в qt creator?
Лично я отлаживаю более привычным для меня способом: посредством диагностических сообщений (UART, USB), а также с помощью логанализатора и осциллографа. Пока еще ни разу не испытывал потребности во внутрисхемной отладке.
В принципе, есть еще вариант — сеггер предлагает посредством jlink в реальном времени сообщения отсылать с меньшей нагрузкой, нежели уарт (как я понял, выделяется область памяти с флажками и собственно сообщениями, а jlink периодически это мониторит). Но я — не сторонник уж такой лохматой проприетарщины, чтобы вместо stlink'а jlink использовать.
Честно говоря, st-link я использую в основном лишь для STM8, а STM32 прошиваю встроенным бутлоадером либо через UART, либо через DFU.
Для инициализации периферии те же ST давным-давно написали набор очень хороших сниппетов (жаль только, что они лишь под STM32F0, но и на другие семейства их несложно перенести). Ну, а остальная логика все равно пишется руками, так что все эти SPL, HAL, opencm3 — излишества. По сути, если пользоваться дополнительно внешними библиотеками, придется не только RM+даташит на МК читать, но и документацию на библиотеку (да и частенько в ее код заглядывать, когда наткнешься на баг или тормоза).
Портянки легко читаются и подправляются, а вот сниппетами можно знатно наколхозить, и если ресурсы не жмут, лучше кубом.
Если ресурсы жмут, а плата разведена, например, под 20 ног (и 32к флэша — потолок), можно подсмотреть сниппеты
Если же поддерживать надо, то только полоумный будет в каловских портянках пытаться разобраться вместо того, чтобы целиком полноценный свой код написать.
И да, свои сниппеты — это вещи, проверенные временем. Уж всяко надежней, чем кал (в котором, кстати, до сих пор косяки находят).
И с недавних пор даже научились делать однонаправленный UART не только в GUI, но и на деле (раньше «говоришь» «мне uart только на выход», а в портянке все равно 2 ноги).
i2c — ужасный.
spi — с пивом норм, хоть и есть нюансы.
usb — вполне.
dma — ужас подающий надежды
таймеры — так же
Еще из минусов, в библиотеках меняют названия функций и бибы одного куба даже по названиям функций не совместимы с другим, для поддержки нужен будет зоопарк кубов, за это бы ноги надо вырвать. И прототипы кидают не в .h файлы, а в текущий .c файл. Экплипс такое недолюбливает.
Но, в принципе, все терпимо, если опыт есть. Может, допилят до чего годного.
Сниппеты все на CMSIS и были узкие места, которые в сочетании с другими задачами работать не будут (опять, таки, если нет опыта). А ремапнуть ноги какого-нибудь интерфейса для человека неподготовленного может занять целую вечность. Кто умеет, тот и без сниппетов накидает, просто глядя в RM.
Итого, если опыт есть, то наверное пофиг в чем сидеть. Если мало, или передавать дела, то куб наглядней. Если ресурсоемкий проект, то нужен человек с опытом.
Когда Atollic стал бесплатным, я очень обрадовался, потому что это цельная специализированная IDE с множеством полезных инструментов для отладки. Плюс, она отлично работала с дополнением Eclipse для поддержки CMake проектов. Единственное, она использовала старую версию CDT и не поддерживала всех современных фич языка C++. Но была надежда на то, что в будущем это пофиксят.
А потом вышла Stm32CubeIDE и сломала совместимость с CMake плагинами. Хочется работать — генерируюй проект в CubeMX. А когда у тебя CI и всё проекты на CMake + в основном ты пользуешься libopencm3… Пришлось оставить надежду и уйти на VS Code. Очень жаль, что так вышло.
Итак для STM32, есть HAL, LL, opencm3, SPL и CMSIS, что-то еще я забыл?
при этом
SPL — только для STM32. Устарел.
LL — только для STM32. Генерится с помощью Stm3CubeMX. Устарел.
HAL — только для STM32. Генерится с помощью Stm3CubeMX.
opecm3 — для разных производителей, но поддержка моделей МК страдает. Есть github и можно вносить правки.
CMSIS — для всех Cortex. То что на сайте ARM не то чтобы библиотека, а в основном заголовочные файлы с названиями и описаниями функций. Тела предлагается реализовать самостоятельно.
Итак вопрос, есть ли CMSIS для Stm32?
Есть ли производители, которые реализовали CMSIS для своих МК?
STM32 + CMSIS + STM32CubeIDE