Я планировал написать несколько постов, рассмотрев несколько периферийных устройств микроконтроллера и их конфигурирование в STM32CubeMX. Но эти посты не заменяют фирменной документации и не претендуют на полноту. В них будут рассмотрены только некоторые, наиболее, на мой взгляд, типичные, примеры использования периферии STM32.
Надеюсь, кому-то этот материал будет полезен.
1. Небольшое введение
Сначала сделаю небольшое пояснение. Для изучения данного материала вам понадобится отладочная плата с микроконтроллером STM32. Я использую плату STM32F746G Discovery, которая на сегодняшний день является одной из самых лучших, и, соответственно, дорогих плат семейства Discovery.
Однако для освоения большей части материала будет достаточно любой, даже самой простой платы на STM32. Я рекомендую именно платы Discovery, т.к. они уже содержат отладчик ST-Link, и для работы вам понадобится только кабель MiniUSB. Для начала не нужен даже источник питания, плата питается через тот же кабель.
Естественно, при использовании микроконтроллера, отличного от STM32F746G нужно будет делать поправки в проектах на другую тактовую частоту, другую распиновку и т.п., но суть остаётся той же. Рекомендую сразу скачать документацию к вашей плате с принципиальной схемой и pdf на микроконтроллер.
Для дальнейшей работы будет неплохо иметь осциллограф, практически любой, однако начать можно и без него.
Опять же, предвидя вопросы про покупку платы, я покупал на aliexpress, и это обошлось гораздо дешевле, чем у отечественных продавцов.
Ещё нам понадобится сам STM32CubeMX (скачивается бесплатно), и любая IDE для работы с проектом на С и поддержкой ST-Link. Их много, есть коммерческие, есть бесплатные, и я намеренно не буду приводить никаких названий. Каждый выбирает для себя.
2. Hello World, или управление светодиодом
Сначала вам нужно скачать и установить STM32CubeMX. Скачать можно бесплатно с сайта st.com. Скажу сразу, STM32CubeMX существует только в Windows-версии. Пишут, что нормально работает под wine, я лично не пробовал.
Заходим в File/New Project, выбираем нужный микроконтроллер. Для этого удобно пользоваться фильтрами в верхней части окна.
В нашем случае это STM32F746NGHx.
Далее настраиваем тактовый генератор. Во вкладке Pinout выбираем работу с внешним кварцем:
Во вкладке Clock Configuration в поле HCLK (MHz) пишем 216. В ответ получаем сообщение «No solution found using the current selected sources. Do yoy want to use other sources?» Отвечаем «OK» и выбираем источник HSE в мультиплексоре PLL Source Mux. Значения PLLM, PLLN и PLLP устанавливаем, как показано на рисунке. Проверяем, что HCLK = 216MHz.
Теперь надо сконфигурировать GPIO, управляющий светодиодом. Это порт PI1. На вкладке Pinout находим вывод PI1, кликаем на него и устанавливаем в значение GPIO_Output.
Для дальнейшего удобства можно присвоить пину имя. Это делать необязательно, но давайте это сделаем, чтобы код был более читаемым. Для этого на вкладке Configuration в столбце System нажимаем кнопку GPIO.
Попадаем в окно «Pin Configuration» и в поле User Label пишем «Led».
Сейчас можно сгенерировать код (Project/Generate Code). STM32CubeMX генерирует не только исходный код, но и файлы проекта для ряда популярных IDE. Обратим внимание, что в коде расставлены комментарии вида:
/* USER CODE BEGIN 3 */
/* USER CODE END 3 */Свой код можно писать только в них, иначе при повторной генерации исходника ваш код будет затёрт.
Итак, находим цикл while(1) в main() и пишем в нём следующее:
HAL_GPIO_TogglePin(Led_GPIO_Port, Led_Pin); //Toggle the state of pin
HAL_Delay(500); //задержка в мсСейчас можно запустить проект. Подключаем плату и загружаем прошивку. Светодиод на плате должен мигать с частотой 1Гц.
Однако приведённый выше подход не идеален. Функция HAL_Delay содержит внутри пустой цикл, и наша программа не может заниматься в это время ещё чем-то полезным. Для решения проблемы есть два пути: использование прерываний и использование операционной системы реального времени. Про операционную систему я напишу в другой раз, а работу с прерываниями мы освоим сейчас.
3. Таймер и прерывания
Настроим таймер, например TIM1. Для этого во вкладке Pinout выбираем для этого таймера источник тактирования:
Источником тактирования стала внутренняя тактовая частота периферии, равная для нашего случая 108MHz. Уточнить это значение или изменить его путём деления главной тактовой частоты можно на вкладке Clock Configuration.
Теперь переходим на вкладку Configuration и настраиваем частоту срабатывания таймера. Нажимаем на кнопку TIM1 и в появившемся окне во вкладке Parameter Settings задаем значения Prescaler и Counter Period. Обратите внимание, коэффициенты деления должны быть уменьшены на 1 от нужных значений. На самом деле, частота прерываний таймера может быть найдена по формуле:
Update_event = TIM_CLK/((PSC + 1)*(ARR + 1)*(RCR + 1))
В нашем случае частота будет равна 108e6 / ((53999 + 1) * (999 + 1)) = 2Hz. При этом частота мигания светодиода составит 1Hz, как в предыдущем примере.
Теперь на вкладке контроллера прерываний (NVIC Settings) нужно разрешить прерывание TIM1 Update:
На этом работа в STM32CubeMX закончена, можно сгенерировать код. В исходнике нам в первую очередь нужно запустить сам таймер, а затем вставит обработчик прерывания, который будет мигать светодиодом:
/* USER CODE BEGIN 0 */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance==TIM1) //check if the interrupt comes from TIM1
{
HAL_GPIO_TogglePin(Led_GPIO_Port, Led_Pin); //Toggle the state of pin
}
}
/* USER CODE END 0 */
int main(void)
{
...
/* USER CODE BEGIN 2 */
//запуск таймера
HAL_TIM_Base_Start_IT(&htim1);
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
//главный цикл пуст, в нём можно делать что угодно.
}
/* USER CODE END 3 */
}
Компилируем и заливаем прошивку. Как и ожидалось, светодиод мигает точно так же, как и в предыдущем примере. Однако, так как сейчас это происходит по прерыванию, процессор свободен для выполнения любых других задач.
4. Что дальше?
На этом я заканчиваю первую часть. Что планируется дальше? В следующей части я планирую описать работу с встроенным ЦАП и затронуть тему DMA. В качестве небольшого анонса: мы научимся генерировать вот такую красивую синусоиду:
(Эта синусоида не очень красивая, на самом деле, но будет лучше).
В дальнейших планах: работа с контроллерами USB (для начала в режиме VCP, виртуального COM-порта), контроллера Ethernet, АЦП, и, возможно, затронем тему использования FreeRTOS.
Комментарии (50)
kiltum
26.09.2016 08:24+3Скажу сразу, STM32CubeMX существует только в Windows-версии. Пишут, что нормально работает под wine, я лично не пробовал.
Он существует и в linux и даже в os x версии. Это «обычное» java-приложение.
hint: в new project есть board selector. Там можно выбрать конкретную плату и сразу получить проинициализированную периферию именно для этой платы.
32bit_me
26.09.2016 08:35Спасибо, попробую. Но в данном случае надо инициалы зимовать не всю периферию, а только некоторые устройства.
pftbest
26.09.2016 23:33Там все хорошо сделано, пины назначены (светятся оранжевым) но вся периферия выключена. Когда включаешь что-то, то его пины становятся зелеными. Так сразу видно какие пины свободные а какие чем-то заняты.
AlexPublic
26.09.2016 08:48-1BGA монстр из серии F7 в роли мигателя светодиодами — это конечно весьма забавно. Но мне кажется что здесь в качестве примера лучше подошло бы что-нибудь из серии F0 в корпусе TSSOP20 — как-то адекватнее и по цене и по сложности и по мощности.
32bit_me
26.09.2016 08:50Я, кажется, написал, что подойдёт любая плата Discovery.
AlexPublic
26.09.2016 09:10Само собой. Просто F7 — это уже несколько нестандартный продукт в мире МК, который ближе скорее к полноценным ЦПУ, т.к. позволяет запускать полноценные ОС.
engune
26.09.2016 09:53+1Сам увлекся программированием для микроконтроллеров, посмотрел на суммарное количество инструментов для OSX и понял что нужно писать свою среду разработки. В качестве встроенного инструмента планирую в следующей внедрить аналогичный генератор себе. Кому интересно, может погуглить Stm32Box.
Wandy
26.09.2016 11:49+1Как Вы вовремя! Вчера вечер потратил на выбор микроконтроллера с низким потреблением и размышления на тему «пора переходить на ARM». Буду должен.
Disminder
26.09.2016 13:27+2Есть возможность использовать Sublime Text 2 как более-менее нормальную IDE для STM32 (отладка, прошивка, запуск CubeMX прямо из редактора). Для себя собирал seed-проект под эту тематику. Нужно будет посмотреть, обновили ли ключевые плагины под ST3, да пересобрать всё это под него.
Будет ли интересна статья на эту тему? Просто она, фактически, будет адаптацией уже существующих статей к текущим реалиям (если сборка такого проекта сейчас вообще возможна, зависит от плагинов).
r1000ru
26.09.2016 14:37+1Для удобной работы и компиляции в GCC под Windows (я использую в качестве редактора Visual Studio Code в качестве редактора) рекомендую:
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-файл, иипортировать из него переменные и отлаживать их в реальном времени.
Thehavoc
26.09.2016 18:23+11) Очень рад, что на хабре появляются такие статьи по современным библиотекам, полгода назад мне их очень не хватало, когда переходил с avr и pic на STM32.
2) С точки зрения курса «STM32 с нуля» — данная отладка совсем не лучший вариант. Объясняю, почему: другая архитектура относительно ядер Cortex M4,M3,M0(+) — Кэш данных, кэш команд, 64-бит шина данных, суперскалярность, ветвление в 1 такт.
Данный процессор — мощный агрегат для ЦОС, и содержимое отладки как бы намекает: микрофоны с PDM-сигналом на выходе, требующим цифровой фильтрации, интерфейс для подключения видеокамеры, жирный дисплей с сенсором. Все это добро требует нехилых вычислительных мощностей на обработку, и без хорошего понимания математических основ ЦОС даже этот контроллер не сможет выполнять свои функции полноценно, так-что этот камень не претендует на нишу «STM32 с нуля» совсем.
Для начала лучше всего пойдет любая отладка на ядре Cortex M3/M4, с небольшим количеством внешней периферии(светодиоды, кнопочки, датчики ускорения/углового ускорения, например), но с большими гребенками и выведением всех свободных выводов на них, где каждый из выводов можно пощупать тестером или осциллографом.
Там и все интерфейсы связи доступны, и микроконтроллеры вписываются в общую концепцию.
Так, например, держа в уме отличия Cortex M0 и M4, можно без проблем писать код и на то и на другое ядро, и даже ожидать соизмеримой производительности (с точностью до DSP инструкций и некоторых других нюансов, в среднестатистических проектах разница в скорости выполнения одной и той же программы там и там — порядка 10-15 %, а скорость обмена данными по интерфейсам связи так вовсе не отличается при равной тактовой).
32bit_me
26.09.2016 19:02Частично я с вами согласен, но только частично.
Во-первых, я пишу цикл статей не про архитектуру Cortex M7 и не про данную отладку. Я пишу про STM32CubeMX. Я сразу написал, что подойдёт практически любая отладка.
Лично я купил эту плату не столько из-за ядра или возможностей ЦОС, сколько из-за Ethernet, USB и, главное, отличного дисплея с емкостным сенсором.
Насчёт того, что пинов на гребенки нужно выводить побольше, согласен. Видел плату тоже на STM32F7, без дисплея, но с Ethernet+USB, и с большими гребенками выводов. Для DIY очень годный вариант, и стоит вдвое дешевле, чем эта плата.
А код можно писать, вообще ничего не зная об ядре, просто на С.Thehavoc
26.09.2016 19:23Тут тоже с вами согласен, но тоже частично.
Моё мнение в том, что 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 микросекунды. Устраивает вас такое время обработки прерывания? Если да — пожалуйста, не нужно разбираться в ядре, в регистрах и библиотеках.
32bit_me
26.09.2016 19:58Я и пишу про вхождение.
Как правило, для большинства практических задач, нет необходимости считать такты до такой степени. Разве что оптимизировать прошивку под обработку сигналов. Но здесь опять же, такая оптимизация имеет практический смысл только для очень небольшого диапазона задач, где сигналы достаточно высокочастотные, или обработка достаточно сложна, чтобы контроллер не справлялся без оптимизации, и в то же время, достаточно низкочастотные, чтобы он вообще справлялся. Для реальных задач обработки сигналов в real-time нужны FPGA, и они есть, в том числе и с встроенными ядрами ARM. Но это уже совсем другой уровень, и по сложности, и по стоимости.snowSTAFF
27.09.2016 05:51Конечно, Вы правы, что для вхождения не нужны такие дебри. Однако, было бы огромным плюсом Вам и всем читающим, сделать спойлер «а теперь сделаем <по-взрослому>», где Вы перерабатываете код и говорите об избыточности HALa.
Польза от этого очевидна: уменьшение количества тактов на выполнении кода позволит не только повысить производительность, это позволит уменьшить энергопотребление(!), что так модно в век wearable и IoT32bit_me
27.09.2016 05:53Это было бы полезно, но как-нибудь в другой раз.
Пока я хочу привести несколько примеров использования различной периферии.
Falstaff
27.09.2016 09:31+1Простите что вмешиваюсь, но так ли очевидна польза? Из практики, HAL не так уж часто стоит на каких-то критических путях выполнения, где он делает большой вклад в общую производительность или задержки, и эти пути вполне можно оптимально переписать руками, HAL не настолько толстый сам по себе. Да и в контексте IoT о производительности не всегда приходится говорить — многие устройства всю жизнь спят, им всё равно, что в остальном коде творится. Избавившись же от HAL, вы потеряете полезный слой абстракции, который облегчал вам разработку.
AlexPublic
26.09.2016 20:23Лично я купил эту плату не столько из-за ядра или возможностей ЦОС, сколько из-за Ethernet, USB и, главное, отличного дисплея с емкостным сенсором.
Ну вот ethernet — это действительно привилегия мощных МК (начиная с F4) и если он реально нужен, то выбор конечно же оправдан (но опять же это будет не самый стандартный расклад для мира МК). Что касается всех остальных упоминаемых в статье и комментариях возможностей (таймеры, dac, usb, тачпадов и т.п.), то поддержка подобного имеется начиная с самой младшей (F0) серии.
VioletGiraffe
Ваш цикл (я надеюсь!) статей очень кстати. Я вчера почти весь день убил, пытаясь собрать хоть в чём-нибудь код, сгенерированный STMCube. Первый свой проект я делал в Eclipse + GNU ARM Plugin, но собрать это в нём — без шансов. В итоге установил IAR и там собрал и даже запустил, хоть и не без проклятий и ещё часа гугления.
В какой IDE вы разрабатываете, что пореуомендуете?
32bit_me
Я не хотел бы обсуждать здесь IDE, чтобы не вызывать холиваров, и не пропагандировать установку нелицензионного ПО.
Но могу сказать, что вы на верном пути.
AlexPublic
Что бы собрать какой-то проект для stm32 (в том числе и сгенерированный STMCube) не требуется вообще никакая IDE. Нужен исключительно компилятор C/C++ для ARM (например gcc) и всё. Ну и драйверы ST-Link/V2 (с сайта ST) для собственно прошивки полученного бинарника в МК. Для удобного управления данным процессом обычно ещё используют какую-то современную систему сборки (CMake/GYP/scons/waf и т.п.), но это исключительно для удобства, а не обязательное требование — для первоначальной сборки достаточно просто командной строки.
А IDE — это для удобства навигации по коду, автодополнения, рефакторинга и т.п. удобств в написание кода, а не для сборки готовых исходников.
VioletGiraffe
Ну, да, кроме как просто собрать скелет, я хотел бы ещё какую-то свою функциональность дописать :)
И даже отладить.
32bit_me
Именно. Навигация пр коду, это хорошо, но проекты для микроконтроллеров редко бывают огромными. А вот интерактивная отладка очень нужна.
AlexPublic
Кстати, а вот насчёт отладки есть интересный нюанс, т.к. в мире МК основные затруднения возникают скорее в режиме реального времени и соответственно плохо отлаживаемы в классических пошаговых режимах (т.е. сама то отладка без проблем реализуется, только смысла от неё нет, т.к. все тайминги всех протоколов нарушаются). И соответственно тут больше помогает осциллограф плюс например такой интересный инструмент как STMStudio (так же как и драйверы для st-link/v2 бесплатно качается с сайта ST).
32bit_me
Пошаговая отладка остаётся очень полезным инструментом, хотя насчёт таймингов вы правы. Просто отладка проекта под микроконтроллер, это немного другой уровень чёрной магии, чем в обычном программировании. Умение работать с осциллографом/логическим анализатором, разумеется, абсолютно необходимо.
AlexPublic
Ну лично я бы мог порекомендовать QtCreator в роли C++ IDE. Но в целом подходит вообще любая, и Eclipse и VisualStudio и Netbeans и CLion…
32bit_me
Надо будет попробовать QtCreator, пока это самая правильная IDE, которую я видел.
AlexPublic
Там кстати есть встроенная поддержка программирования для МК. Причём если для других МК потребуется настроить OpenOCD, то для st-link есть отдельная нативная поддержка, которую не надо настраивать.
VioletGiraffe
Я бы тоже мог порекомендовать Qt Creator и билд-систему qmake для десктопных С++ проектов (и Qt проектов для Android / iOS). Как его использовать для STM — ума не приложу, если я даже в Eclipse c GNU ARM плагином не смог собрать код, сгенерированный STMCube. И в EmBitz не смог (который бывший EmBlocks — embedded IDE на базе Code::Blocks).
AlexPublic
Ну вообще то qmake — это достаточно убогая система на фоне современных решений. Но и её более чем достаточно для данных примитивных целей.
А в чём собственно затруднение? Сборка под МК на базе ARM ничем не отличается от сборки обычного десктопного приложения с помощью gcc. Вся разница исключительно в нескольких дополнительных опциях компилятора (и то они в основном для экономии памяти) и одной опции компоновщика.
Кстати, а опции самого STMCube стоят правильно? ) Там есть существенные различие в настройка генерации. Причём разница не только в формате проектов целевых IDE, но и в режиме формирования каталогов исходников (добавлять библиотечные файлы или нет и т.п.).
VioletGiraffe
Не трогал опции Cube, ничего о них не знаю.
Главная проблема со сборкой — как-раз таки в бибилиотеках, peripheral library, HAL и всей этой ерунде.
AlexPublic
Там вообще много разных интересных настроек по генерации исходников. Но для конфигурации дальнейшей сборки принципиальны только две:
1. Целевая IDE для которой генерируется проект. И хотя сам сгенерированный проект (в смысле файлы настроек IDE) мы не используем вообще, но от этой настройки зависит и создаваемая структура проекта. Лучше всего ставить SW4STM32 — будет меньше всякого мусора и будет всё нужное для gcc.
2. Как раз используемые библиотеки. Там есть варианты: добавить сами библиотеки, добавить в проект только нужные файлы из них, добавить ссылки на них (в смысле только #include и прописанные пути к библиотекам в настройках проекта). Соответственно для разовой сборки лучше всего ставить второй вариант, тогда просто в папке проекта будет всё нужное для сборки. Ну а лично у меня все библиотеки (HAL и т.п.) уже заранее собраны и настроены отдельно, так что я всегда использую 3-ий вариант.
VioletGiraffe
Спасибо. У меня тоже используется вариант «скопировать только нужные файлы», но это мне не слишком помогло (пока не поставил IAR, в которой можно просто открыть проект. И то, там не все нужные настройки были прописаны, но гугл помог — теперь всё собирается, работает и даже дебажится).
Thehavoc
С точки зрения оптимизации кода(и по скорости и по размеру) компили IAR и Keil показывают существенно лучшие результаты, нежели SW4STM32. Только есть два но:
1) Они платные.
2) Текстовые редакторы не намного лучше, чем блокнот.
Для некритичных по времени выполнения программ — SW4STM32 — хороший вариант, себе на линукс дома поставил и пользуюсь.
На работе же на машине стоит IAR, уже давно привык к его редактору кода, им и пользуюсь.
Falstaff
А есть какие-то сравнения на предмет размера кода и скорости? Я не для холивара, а интереса ради; как я понимаю, у SW4STM32 под капотом gnu toolchain — там много что можно подкрутить в случае необходимости.
AlexPublic
Если говорить про компиляторы (а не про IDE, хотя у вас тут озвучены они, но на самом деле они ни при чём), то возможно указанные продукты и генерируют изредка чуть более оптимизированный под конкретный МК код в сравнение с gcc. Но при этом это полностью нивелируется отвратительной поддержкой современного стандарта языка (я про C++14 и т.д.), которая не позволяет писать современный быстрый и одновременно красивый код.
golf2109
Для того, чтобы сделать (а не «собрать») и сдать заказчику проект без IDE, приспособленной для STM32 в обойтись невозможно.
asakasinsky
С помощью CubeMX генерируем проект для IDE SW4STM32, затем, с помощью https://github.com/baoshi/CubeMX2Makefile творим магию
VioletGiraffe
Интересно, спасибо!
lohmatiyy
Здорово, сейчас как раз пытаюсь привести к виду, в котором не стыдно выложить, то же самое для CMake.
asakasinsky
Обязательно поделитесь! Сам только начал копать в эту сторону, пока сказать нечего.
lohmatiyy
С какой целью, если не секрет? Мне это нужно из-за острого желания прикрутить CLion(очень уж нравятся продукты Jetbrains), который использует CMake и пока что не признаёт альтернатив. Делал на основе CMake-скрипта из туториала на их сайте.
В том генераторе, кстати, есть мелкая ошибка, зарепортил.
Falstaff
А вы хотите именно с интеграцией STM32CubeMX? CLion для STM32x вполне можно использовать, очень комфортно, но Cube интегрировать порывов не было — во-первых, у него на момент рассмотрения были нелады с Linux, а во-вторых, делать инициализацию руками как-то гибче.
lohmatiyy
Я просто с Cube начинал, так что вопрос привычки, насчёт гибче — не знаю даже, поделитесь примерами, где он не справлялся? Так-то я и руками могу, оно и кошернее, но Cube нравится за наглядность, особенно в распиновке и настройке тактовых частот. Насчёт неладов: это упакованное Java-приложение, на просторах сети есть мануалы по запуску в Linux, проверял лично — работает.
Falstaff
Дело давно было, Cube тогда ещё был сырой — тогда пробовал, но у него ещё был капризный .exe внутри, с тех пор, видимо, далеко шагнул. Мой сценарий — затяжные проекты с несколькими целевыми платформами (разные ревизии железа, разные распиновки, периферия), настройка тактовых частот и источников тоже меняется в процессе работы, периферия включается когда нужно, что-то отключается в энергосберегающих режимах — сгенерированные куски при таком раскладе уже не так полезны. Плюс иногда попадаются баги в HAL, совсем не лезть куда-то руками не получается (в последнем на момент написания инициализация WWDG сломана, например). Но, да, не очень распространённый use case, так что я от Cube не отговариваю, мне просто интересно было.
lohmatiyy
За баги в WWDG не скажу, но когда они только начинали вводит поддержку серии F1 доходило до смешного, типа неправильных имён констант в инициализации, так что к ST со всем, что она сделала поверх старого доброго CMSIS вопросов много, это да.