Комментарии 49
А так, да добро пожаловать в клуб любителей STM -ок на ХАБРе.
а на старшие STM32 вполне успевают обрабатывать видео налету и принимать решения.
топовые же STM32 тянут полновесные CNN сетки типа MobileNetV2 и говорить можно не о секундах на кадр а о FPS, естественно всё в реалтайме.
Но дальше мигания светодиода, почему то почти никто не рассказывает.
Обидно. Мне кажется что у многих «аллергия на мигание светодиодом» просыпается.
Я бы для стартового проекта поднял бы уарт. Почему? Любой язык начинается с Hello world а для этого нужен printf, но для printf нужен uart. Если есть хотя-бы он то всё остальное сделать в разы проще. Я всегда начинаю с уарта и printf/scanf, будь то FPGA, MCU или малинка в baremethal. Более того простой printf/scanf можно вполне впихнуть в пару тыщь байт или LUT/reg ячеек. Т.е. он влезет КУДА УГОДНО и ещё останется чтоб поднять и наладить любую другую периферию. А подымать и настраивать периферию удобнее если ты можешь в реалтайме выводить события, состояния регистров в бинарном хекс и десятичном значении и видишь всю динамику такой какой она есть. Да и поднять уарт в разы быстрее чем довести до ума отладчик и тд. Uart это логи! Это удобные текстовые команды устройству в реалтайме без перекомпиляции (для FPGA это часы и сутки!), это не только экономия времени и нервов а ещё и видиние реальной работы устройства не прерывая и не останавливая переферию дебаггером!
Не смотрите через замочную скважину светодиода на мир, откройте чёртову дверь UARTa!
Не забывайте про уарт, uart хороший, uart ваш друг!
Добавлено: Sdima1357 Надеюсь моя uart «доктрина» заслуживает STM32 больше чем мигание светодиодом?
Есть классы для uart, spi, can. К примеру, для urat сделан modbus rtu, wake.
Ну наверное. Я например на нем Синклер — Спектрум эмулятор habr.com/ru/post/412325 писал для начала.
То есть светодиод ту меня был конечно, но я решил не делиться таким результатом.
Тут много неплохих статей на про stm на хабре
Отличная статья, продолжай в том же духе!
В начале вы пишите:
Когда я попытался сделать первый проект меня ждало разочарование — CMSIS! Кому как, но для меня это было (и остается) ужасом: много буков, длинные и для меня не понятные структуры. Вникать во все это было не интересно.
А ближе к концу углубляетесь еще «ниже» и пишете свои структуры, причем оперируйте адресами регистров, которые в CMSIS уже прописаны.
В ваши структуры тоже нужно будет другим вникать.
Смысл?
Одно дело пользоваться этими структурами в пользовательский части кода, другое дело, когда они спрятаны внутри классов.
Навскидку USB host,Ethernet,sd card, не работают как положено, и полно багов.
Вот тогда и приходится ковыряться
Только в первом случае, придется ковыряться в исходниках компании разработчика, имея возможность найти решение проблемы в интернете. Если с ним кто-то уже сталкивался.
И совсем другое дело, когда проблемы возникают с посторонней библиотекой, которую кроме автора мало кто использует.
www.st.com/en/embedded-software/stsw-stm32068.html
Семейство нужное выбирай и качай.
Поддержу, Sdima1357 Cube генерит столько кода… чтобы поморгать светодиодом. Это универсальная библиотека для быстрого прототипирования, она не годится для нормальных продуктов, связанных с надежностью.
Быстро что-то проверить -самое то, но писать продуктовый код на ней не лучшее решение (ИМХО).
Это универсальная библиотека для быстрого прототипирования, она не годится для нормальных продуктов, связанных с надежностью.
Пример «нормальных продуктов» в студию. Обычно такие аргументы у диванных теоретиков.
Да любой промышленныйи датчик. Ну вот, например, https://www.emerson.ru/ru-ru/catalog/metran-150-ru-ru
Вы ни одного сертификата безопасности не получите с авто-сгенерировангой ерундой из Cube. Либо придется всю эту лапшу проверять юнит тестами… Вы как себе это представляете?
Вы ни одного сертификата безопасности не получите с авто-сгенерировангой ерундой из Cube.
Ну открой сертификаты твоего же датчика и найди там упоминание госта на говнокод. Его серьифицируют по точности измерений, рабочим температурам, электромагнитным помехам и прочим параметрам, измеряемым снаружи. В код к нему никто не лазит.
Либо придется всю эту лапшу проверять юнит тестами… Вы как себе это представляете?
Советуешь без тестов обходиться?
Датчик давления. Ясно. Я уж думал что-нибудь вроде контроллера в газовой котельной будет.
А в чем отличие? Контроллеры тоже есть и другие устройства… Вы просили пример, я дал, могу еще....
Ну открой сертификаты твоего же датчика и найди там упоминание госта на говнокод
Я знаю как их сертифицируют. А вы знаете? Есть много сертификаций. Вот например на соответствие этому ГОСТу:
ГОСТ Р МЭК 61508-2012, на самом деле просто перевод IEC 61508
А я вам скажу, лезут в код, подписывают NDA и лезут везде, смотрят покрытие всех требований к функциональной безопасности в архитектуре, юнит тестах, коде, смотрят отчеты линта и аргументы по бану некоторых сообщений. Вся методика там в ГОСТе и описана. А приведенный в пример датчик имеет такой сертификат.
Сертификация соответствия требованиям международного стандарта функциональной безопасности IEC 61508 с уровнем полноты безопасности SIL 2 (SIL 3 при соблюдении требований) с предоставлением отчета анализа отказов, их последствий и диагностики (FMEDA)
И если вы думаете это фигня, то имейте ввиду, что датчиков на этой платформе уже выпущено 1 млн. Мало того, вам после того как вы сертификат получили, код, связанный с функциональной безопасностью менять нельзя. Иначе снова показывать код, аудит и подтверждение сертификата.
У STM есть специальная библиотека для тестирования ядер микроконтроллеров, так как аппаратная часть микроконтроллера относится к сефети критикал параметрам. Вот она имеет сертификат, ее можно в нормальных продуктах использовать, а не поделках. Но там нет ничего связанного с генерацией кода, эта библиотека пришита гвоздями (SHA256) при сертификации и вы не можете ничего там менять. А вот и сам сертификат https://www.st.com/resource/en/certification_document/x-cube-stl_certification_tuv_rheinland.pdf Да и там нет ни HAL ни макросов, в основном все на ассемблере. Прочитать тут можете:
https://www.st.com/content/st_com/en/functionalsafety.html
И тут
https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-stl.html
Поэтому Cube CMSIS и вся автогенерация, это все для быстрого прототипирования, поделок и ширпотреба.
Советуешь без тестов обходиться?
Нет, ну просто представляю, сколько надо времени, чтобы HAL покрыть, да даже просто I2C, там же черт ногу сломит с бранчами. Она универсальная, а как любая универсальная вещь избыточна. Там для реального проекта нужно может только 2 простых метода, а придется всю лапшу покрывать тестами, иначе покрытия не будет и не зачтется вам эта библиотека и сертификат вы не получите.
А такая же фигня еще и с RTOS творится. FreeRTOS никто в нормальных продуктах тоже использовать не сможет, зато ее клон SafeRTOS, пожалуйста.
https://www.highintegritysystems.com/safertos/
В общем, не для промышленных целей она сделана была, а для упрощения вхождения в разработку на микроконтроллере, быстрого прототипирования, проверки идей.
А кубик поддерживает миландровские контроллеры?
Оборачивание регистров в битовые структуры — не уменьшает количество Си кода, и значительно увеличивает размер бинарного кода. Метод от самой ST — тоже болеет этой фигнёй. Идеального решения не существует, и никакие библиотеки с новыми методами тут не помогут. Если в регистре есть 32 отдельных поля для записи — то все 32 поля придётся описать. Описание должно быть в одном месте, без размазывания по всему проекту. Хотя данное требование не относится ко всему что есть в мк.
Откройте для себя макросы _VAL2FLD и _FLD2VAL, это позволит частично сократить чтение документации, и значительно сократить время поиска ошибок. Основной бонус этих макросов — отсутствие дополнительного слоя абстракции, CMSIS используется как есть — в собственном соку.
1) Вообще, после фразы «Когда я попытался сделать первый проект меня ждало разочарование — CMSIS! Кому как, но для меня это было (и остается) ужасом: много буков, длинные и для меня не понятные структуры. » программиста можно выгонять с собеседования, так как это явно не эмбеддер, язык С он точно не знает, как следствие и С++ тоже.
Ну да:
RCC_APB2ENR_bit.ADC1EN = 1;
RCC->APB2ENR |= RCC_APB2ENR_ADC1EN;Эти записи такие разные, явно стоит вендорлока, ещё и свой аналог для описания регистров нагородим. Вы же его автоматически генерируете? И тесты у вас есть?
2) IAR — компилятор для профессионалов(нет). Только в заголовке будет запись типа:
#error This file should only be compiled by ARM IAR compiler and assembler
IAR платный, а вы не оставляете мне возможности собрать проект другим компилятором. Может быть мне его купить за 2-3к$? А у вас он куплен?
Под линукс он не поставляется, наверное, придется ещё и винду покупать. Ну да ладно: «Я привык работать в IAR. Да, есть другие IDE, но мне хватает возможности IAR».
3) Как правило, начинающие разработчики изучают С++ со стороны ООП и это вполне себе оправданно, но это не серебряная пуля. C++ — мультипарадигмальный язык программирования, наиболее мощными возможностями которого являются метапрограммирование и программирование в пространстве типов, позволяющие сгенерировать оптимальный код, который так важен в эмбеддед.
Все расчеты в коде, который вы привели, можно выполнить на этапе компиляции, сведя все к записям в регистры GPIO, у вас это все считается в рантайме. А если у вас по ТЗ время перехода МК в некое состояние 1мс, при этом настроить нужно 200 ног?
Посчитать на этапе компиляции маски можно вот так
Использование будет примерно таким:
struct LedTrait final: mpp::gpio::LedTrait
{
constexpr static mpp::gpio::Inversion kInversion = mpp::gpio::Inversion::Off;
};
//...
using LedBlue = mpp::gpio::Gpio < mpp::gpio::PD15, LedTrait >;
//...
using Leds = mpp::gpio::IoGroup < LedBlue, LedRed, LedOrange, LedGreen >;А помигать можно как-то так :
Leds::Toggle();Представленный код прошу рассматривать только с академической точки зрения как пример возможностей современнего С++.
Возможно, вам стоит изучить язык более досконально, С++20 рановато брать, а вот С++17 давно мейнстрим. Уже потом учить работников и писать статьи.
Очень хорошая статья на тему, как делать не нужно
Напишите как нужно. Будем учиться по Вашим статьям. Только не отсылайте читать других авторов, ведь интересен Ваш подход и консультироваться с Вами.
начинают делать также, а потом их приходится бить по рукам.
Не повезло Вашим подчиненными, если таковые имеются.
программиста можно выгонять с собеседования, так как это явно не эмбеддер, язык С он точно не знает, как следствие и С++ тоже.
да, хорошо чувствовать превосходство. Только когда появляется на собеседовании человек, который покажет, что Вы плохо знаете, то его тоже отсеете?
Эти записи такие разные, явно стоит вендорлока, ещё и свой аналог для описания регистров нагородим. Вы же его автоматически генерируете? И тесты у вас есть?
Вы о чем?
и да, CMSIS тестируют на пользователях, не просто так вссплывают опечатки и баги.
2) IAR — компилятор для профессионалов(нет). Только в заголовке будет запись типа:
#error This file should only be compiled by ARM IAR compiler and assembler
IAR платный, а вы не оставляете мне возможности собрать проект другим компилятором. Может быть мне его купить за 2-3к$? А у вас он куплен?
Под линукс он не поставляется, наверное, придется ещё и винду покупать. Ну да ладно: «Я привык работать в IAR. Да, есть другие IDE, но мне хватает возможности IAR».
где Вы в коде нашли не совместимость с другими компиляторами? я порекомендовал IAR, т.к. мне он показался удобней. но это не означает, что все поголовно должны перейти на него.
у меня iar не куплен, лицензия (как написано в тексте) ограничение кода. для дома и семьи хватает.
За лицензию платит заказчик, когда я отдаю исходники. И вообще, почему хороший инструмент должен быть бесплатным?
3) Как правило, начинающие разработчики изучают С++ со стороны ООП и это вполне себе оправданно, но это не серебряная пуля. C++ — мультипарадигмальный язык программирования, наиболее мощными возможностями которого являются метапрограммирование и программирование в пространстве типов, позволяющие сгенерировать оптимальный код, который так важен в эмбеддед.
так и расскажите об этом новичкам!
Все расчеты в коде, который вы привели, можно выполнить на этапе компиляции, сведя все к записям в регистры GPIO, у вас это все считается в рантайме.
можно. каждый выбирает свой путь
А если у вас по ТЗ время перехода МК в некое состояние 1мс, при этом настроить нужно 200 ног?
не попадалось. не уверен, что на все случаи жизни можно сделать что-то универсальное.
А помигать можно как-то так :
посмотрел Ваш стиль написания. Красиво. Молодец.
void board::Init() { <b>RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN;</b> board::Systick::Init(); board::ClockCounter::Init(); board::Leds::Init(); return; }
вот только зачем в области пользователя доступ к регистрам?
или если отвечать Вашим стилем: за это надо мордой об экран
Представленный код прошу рассматривать только с академической точки зрения как пример возможностей современнего С++.
можно даже пользоваться, ничего криминального в коде нет
Возможно, вам стоит изучить язык более досконально, С++20 рановато брать, а вот С++17 давно мейнстрим.
буду стараться
Уже потом учить работников и писать статьи.
а кто будет учить работников? ждать Вас? мне нужны специалисты сейчас.
А вот от Вас ждем интересный статей. Я серьезно, поделитесь опытом.
Напишите как нужно. Будем учиться по Вашим статьям. Только не отсылайте читать других авторов, ведь интересен Ваш подход и консультироваться с Вами.
В коде вы используете битовые поля, порядок размещения бит в которых не регламентируется стандартом, т.е. является implementation-defined.
Отсюда, работа с регистрами, требующими строгий порядок бит, через битовый поля выливается в undefined behavior.
Это распространенная ошибка. Ещё чаще используют пакованые структуры, которых в стандарте нет и никогда не будет, для «сериализации» пакетов данных,. Это опять приводит к undefined behavior, привязывающий код к конкретной версии компилятора, на котором он хоть как-то «работает».
Эти подходы нельзя использовать категорически. Вместо битовых полей необходимо использовать маски, а вместо пакованых структур писать полноценные сериализаторы.
Так как IAR использует методику работы с регистрами через битовые поля у себя в библиотеках, то работоспособность подхода гарантируется разработчиками компилятора. Однако другие компиляторы такой гарантии не дают, в этом смысл моих слов о вендор локе, качестве вашего кода и статьи в целом.
Мы эмбеддеры, наша задача — писать надежный код, строго соответствующий стандарту. Давайте оставим право на говнокод ардуинщикам.
и да, CMSIS тестируют на пользователях, не просто так вссплывают опечатки и баги.
CMSIS и svd генерируются автоматически по verilog-модели. С 2013г. я встречал ошибку только один раз в заголовочнике для stm32f411хе.
вот только зачем в области пользователя доступ к регистрам?
Я пока думаю, как это оформить: через профили питания или просто передавать в трейте конфигуратору PLL.
Во всяком случае, код в файлах board платформозависимый, в нем допускается использовать подобный код.
Про битовые поля везде пишут, что не стандартизовано, но при этом компиляторы, которыми я пользовался, вполне предсказуемо компилировали код. Это IAR, Keil, GCC, Visual Studio, code composer studio (TI). Даже интерфейсы с битовыми полями между SystemC и systemVerilog не вызывали проблем.
Для сериализации — да, могут быть нюансы. Но опять же надо понимать, что требуется от компилятора.
Использовать define можно для битовых масок и операций, но читаемость кода исчезает. Да и вообще, моё мнение — define в коде это зло.
В CMSIS были неувязочки с битами, которые отличались от документации. Это замечал и в библиотеках IAR (вроде, DR <>DRR в usart, точно не помню, давно было).
Да и вообще, если открыть community.arm.com там раньше люди писали об ошибках в CMSIS. Правда, давненько туда не заглядывал.
Про ардуинщиков да, много интересного (забавного) можно увидеть в коде. Но с другой стороны — есть много проектов, которые просто работают. Пока я терял время на подготовку своего кода, у ардуинщиков уже все было готово. Ну и пусть они потом 40 раз исправляют косяки, но клиент уже у них.
Иногда ознакамливаюсь с библиотеками для ардуино, когда надо быстро разобраться с каким-нибудь девайсом или дисплеем со встроенным контроллером. Жесть, но взять последовательность цифр для инициализации полезно, хотя-бы на начальном этапе.
И да, я не эмбеддер, я электроник. Программировать пришлось из-за того, что с программистами (которые мне попадались) тяжко договориться. Например, при ошибке программист считает, что программа должна остановиться или вывести модальное окно с ошибкой. А мне в это время надо отладить железку. И вот я руками держу щупы осциллографа, ногой включаю питание, а прога вывела ошибку и остановилась. И как настраивать?..
Да, абстрагироваться до последних версий c++ у меня уже мозга не хватает, но некоторые моменты освоил. Решил поделиться в статье.
Скоро будет продолжение. Рад буду конструктивно обсудить что можно улучшить или упростить.
Под линукс он не поставляется, наверное, придется ещё и винду покупать
Уже вот вот будет… :) Вроде даже уже есть, но пока мне еще не дали.
Посчитать на этапе компиляции маски можно вот так
Там у вас тоже странности в коде есть
inline constexpr static void Init() noexcept(true) {
GPIO_TypeDef* regs { reinterpret_cast<GPIO_TypeDef*>(kPort) };Не будет это работать на этапе компиляции, можно убирать constexpr
Но прикольно, только если это все руками писать, то накладно… если бы генерилка была какая.
Там у вас тоже странности в коде есть
Ревью небыло, так что может что-то подобное всплыть. К сожалению, на текущий момент ключ --pedantic с этим не поможет.
Уже вот вот будет… :) Вроде даже уже есть, но пока мне еще не дали.
Учитывая наличие пакетов типа arm-none-eabi-gcc или аналогичных во всех дистрибутивах, необходимость стремится к минимуму.
Единственное, для некоторых работ может быть нужен сертифицированный компилятор, в таком случае можно рассмотреть IAR или GreenHills. Но это будет одна единственная лицензия для билд-сервера.
Но прикольно, только если это все руками писать, то накладно… если бы генерилка была какая.
Этот момент можно рассмотерть:
- Многие вендоры делают различные конфигураторы для периферии, например, тот же cubemx от ST. В коробке с этими конфигураторами идут файлы с описанием периферии, настоятельно рекомендую заглянуть в папку /db/mcu/IP/
Эти файлы применими как минимум для получения ограничителей/constraints библиотечным модулем или генератором. Именно их я использую для генерации списка пинов. - Не для всякой периферии такая генерация необходима. Вендоры часто консервативны и, как минимум, в пределах серии сохраняют один и тот же набор доступных польхователю регистров. В этом случае затраты для написания шаблона под генератор будут идентичны затратам на написание библиотечного модуля.
- Есть уникальная периферия, например PLL, вот здесь генератор может пригодится. Но шаблон для генератора придется писать., что для какого-нибудь stm32h7 задача крайне не тривиальная.
Генераторы для PLL я точно писать буду, но несколько позже. В первую очередь я планирую доделать модули и примеры, не зависящие от железа:
- инжекция конрольных сумм прошивкки в саму прошивку (уже готово)
- Бинарный логгер, заточенный специально под эмбеддед. Есть интересная идея, как организовать печать строк с форматированием, но при этом не хранить их в прошике и не заниматься форматированием значений в рантайме.
Ну в вашем коде тоже есть зависимости от компилятора, вы так же не даёте возможность собрать ваши проекты на других компиляторах.
Например, использование директив pragma. Да, #pragma once поддерживается многими компиляторами, но это не входит в снандарт, и не гарантирует одинаковое поведение. Кроме того, есть мнение, что такая конструкция может наносить "непоправимые" ошибки.
Всё это может отпугнуть только робких программистов. Тру электроник может заточить чужой код под свою железяку.
Ну в вашем коде тоже есть зависимости от компилятора, вы так же не даёте возможность собрать ваши проекты на других компиляторах.
Перечислите, пожалуйста. (Про #pragma ниже). Какие ещё зависимости?
Например, использование директив pragma. Да, #pragma once поддерживается многими компиляторами, но это не входит в снандарт, и не гарантирует одинаковое поведение. Кроме того, есть мнение, что такая конструкция может наносить "непоправимые" ошибки.
Пока не встречал такого. GCC, G++, msvs, IAR, Keil никаких сюрпризов не подсовывали с #pragma once
Всё это может отпугнуть только робких программистов. Тру электроник может заточить чужой код под свою железяку.
Не понял, что может отпугнуть?
Хм. Я отвечал, вроде, @evgeniy1294.
К вам, как к автору. претензий нет.
Страннная претензия Евгения по поводу IAR. Да и какая разница, куплен он или нет? Читатель как-нибудь сам разберется где взять IDE. У меня, например, куплен. И, может, автор ради меня писал статью).
Практически у всех вижу подобный Toggle(), но все же лучше читать ODR и писать в BSRR, как для Set() и Reset(), это медленнее, но безопасно. Еще хуже когда, как у автора статьи, старое значение бита читают из IDR. Например, пин в режиме OpenDrain без подтяжки, тогда из IDR можно прочесть что угодно, а если подтяжка есть, то правильное значение будет читаться до достижения определенных скоростей и два Toggle() подряд для мк работающего на 100+ MHz не гарантирует возврата к первоначальному состоянию.
Практически у всех вижу подобный Toggle(), но все же лучше читать ODR и писать в BSRR, как для Set() и Reset(), это медленнее, но безопасно.
Да, это замечание написано в комментариях
Например, пин в режиме OpenDrain без подтяжки, тогда из IDR можно прочесть что угодно,
Странный случай. OD и без подтяжки. Наверное, Вы хотели написать, что кто-то линию зашунтировал (подтянул к общему). Как, например, i2c и несколько мастеров. Тогда да, вполне реальный пример.
а если подтяжка есть, то правильное значение будет читаться до достижения определенных скоростей и два Toggle() подряд для мк работающего на 100+ MHz не гарантирует возврата к первоначальному состоянию.
Возможно, надо посмотреть с какой частотой работает шина на которой висят gpio. Подозреваю, что она не даст переключать с такой скоростью, что бы пропустить изменение состояния вывода.
А вообще, этот метод (Toggle) в классе лишний, пока не применял у себя, везде писал clk.On(); clk.Off();
Поэтому, не возникало нюансов.
Открываю статью, вижу IAR — закрываю статью.
Почему? Потому что IAR и Keil — пропиаритарны.
Многие возразят: есть же free, с ограничением по размеру кода… или условиям использования…
Отвечаю: есть, но я не хочу приучаться к системе, которая в случае разрастания кода или не дай бог комерциализации моего проекта может потребовать несколько тысяч долларов — сразу.
Я много раз пытался завести STM на Qt+GCC ARM под винды, но ниразу у меня не вышло. (под линух смысла нет, т. к. основная ОС — для моих любительских и учебных проектов — виндовс) Счас мне напихают — Qt тоже пропиоритарен. Отвечу на сколько последний раз сталкивался: Community подразумевает требование публикации исходных кодов даже для коммерческих продуктов. Меня такой подход — на данном этапе возможной комерциализации моих проектов — устраивает.
Последний раз я дрюкался с какой то IDE от самих STM… Вроде работает… Но в STM так и не вступил, и не только из-за геморности с IDE, но и отсутствием подходящего проекта… Простите, но моргать диодиком я уже на AVRкак в доврдуиновскую эпоху наморгался.
Кто нибудь! Напишите нормальную статью именно по старту, для тупых магистров/аспирантов. А то не дай бог, честное слово! самому прийдется начинать писать!
Открываю статью, вижу IAR — закрываю статью...
захожу в магазин, вижу Windows на ноутбуке — выхожу из магазина…
Если Вы учитесь — производители предлагают бесплатно попользоваться, если Вы зарабатыаете деньги, почему другие не должны это делать.
Если Вы обучаете студентов — обратитесь к разработчикам, возможно, есть лицензия для ВУЗов.
А то что бесплатно — придется вручную прикручивать. Тут ничего не поделать.
IAR использует Clang, поэтому вполне себе нормальный он. Основное преимущество, что поддержка есть со стороны производителя и сертификаты и это дефакто стандарт для промышленных компаний (по крайней мере на западе). У него есть 30 кБайтная версия для обучения.
Вообще без разницы на чем делать, код написанный на С++17 должен на любом компиляторе собираться. Там есть тонкости с прагмами и заданием сегментов и встроенных функций, но они минимальны. Все отличия можно в одном файле держать.
Поэтому насчет компиляторов, тут без разницы — для встроенщиков осталось всего два вида Clang и GCC и работать такой код должен везде. А IDE можно любую к ним прикрутить....
В том то и проблема с "быстрым стартом", либо IDE в комплекте с компилятором — платная, либо нужно с бубном попрыгать, что-бы "helloworld" запустить.
И это в случае с STM/ARM. С AVRовским семейством от микрочипа — таких проблем нет.
Я уж не говорю про миландровские "клоны STM f103" — эти только на IARe у нас в конторе смогли запустить.
У них библиотека для дебагера отличается. Вроде, для keil тоже есть, не помню.
Делал на миландр проект, как раз в iar. Жаль, что для stlink ничего не сделали, только j-link. Сначала чип понравился, заработало почти все и сразу. Но потом повылезали нюансы, связанные с особенностью чипа. Errata достаточно объёмная (хорошо или плохо), не все проблемы можно решить. С can там танцы с бубном. Недавно коллеги по несчастью выяснели — частота уходит, будем на неделе изучать феномен.
Самое интересное, что 30 КБ это ограничение на код. На константы, хранимые во flash (например, картинки) я не заметил.
Очередная статья: STM32 для начинающих