Comments 46
Минусы: нет авто дополнения кода.
Поясните, что вы имеете в виду под термином «авто дополнение»? Если классическое дополнению текста по введённой его части, то оно есть. Вводите часть слова, нажимаете Ctrl+пробел, выбираете вариант.
Я, честно говоря, не помню что там с автодополнением слов, но вот чего там нет, так это выпадающих списков полей, после того как написал имя структуры (а вот при работе с регистрами оно _очень_ помогает), а также прочих «go to definition».
Пару лет назад писал конвертор makefile-ов которые генерит Cube в CMake-овские, а потом открывал их взрослой VisualStudio.
Но сравнительно недавно была на хабре статейка про использование VSCode для STM32. Там вроде уже все это есть без плясок с бубнами.
Пару лет назад писал конвертор makefile-ов которые генерит Cube в CMake-овские, а потом открывал их взрослой VisualStudio.
Но сравнительно недавно была на хабре статейка про использование VSCode для STM32. Там вроде уже все это есть без плясок с бубнами.
Поискал чуть. Оказывается не я один такой конвертор писал. Вот тут уже есть инструкция:
habr.com/ru/post/310742/#comment_9828166
habr.com/ru/post/310742/#comment_9828166
И список полей выводит. Причем Эклипс умеет это делать с дремучих времен. Это в свое время заставило меня перейти с IAR на Эклипс.
Большое спасибо за годный туториал!
Как на счёт С++? Хотелось бы знать насколько он вообще применим для STM32 в условиях отсутствия кучи. Можно ли использовать размещающий оператор new, деструкторы, stl?
Как на счёт С++? Хотелось бы знать насколько он вообще применим для STM32 в условиях отсутствия кучи. Можно ли использовать размещающий оператор new, деструкторы, stl?
Есть там heap (даже в AVR есть).
С++11 IAR ARM, насколько я помню, поддерживает. STL, new и т.д. — все работает.
Просто, если используете динамическую память, то теоретически она станет со временем фрагментированной, вы не сможете выделить большой кусок памяти, и программа упадет. С этим можно жить во многих случаях, ведь любая программа на самом деле может зависнуть и её перезагрузит Watchdog. Уменьшить фрагментацию можно, если использовать аллокацию и деаллокацию памяти только в вызовах функций. Чтобы, когда функция завершилась, все выделенные участки памяти, все объекты были удалены. Например, пришла вам строка из UART. Вы в функции ParseString её разбираете с помощью std::string, std::vector и т.д. А возвращаете результат в главный цикл в виде объекта фиксированного размера, размещенного на стеке.
С++11 IAR ARM, насколько я помню, поддерживает. STL, new и т.д. — все работает.
Просто, если используете динамическую память, то теоретически она станет со временем фрагментированной, вы не сможете выделить большой кусок памяти, и программа упадет. С этим можно жить во многих случаях, ведь любая программа на самом деле может зависнуть и её перезагрузит Watchdog. Уменьшить фрагментацию можно, если использовать аллокацию и деаллокацию памяти только в вызовах функций. Чтобы, когда функция завершилась, все выделенные участки памяти, все объекты были удалены. Например, пришла вам строка из UART. Вы в функции ParseString её разбираете с помощью std::string, std::vector и т.д. А возвращаете результат в главный цикл в виде объекта фиксированного размера, размещенного на стеке.
Можно, но на стандартных библиотеках GCC оно отжирает просто фантастические объёмы RAM и ROM под свои нужды. Поэтому — лучше статическое определение классов и их методов.
Вот, как пример такого использования (пока ещё очень сырой вариант, не допиленный до полной инкапсуляции констант и прочего в классы) — github.com/andreili/STM32FX_FM/blob/master/Examples/STM32F4DISCOVERY/src/main.cpp
Вот, как пример такого использования (пока ещё очень сырой вариант, не допиленный до полной инкапсуляции констант и прочего в классы) — github.com/andreili/STM32FX_FM/blob/master/Examples/STM32F4DISCOVERY/src/main.cpp
С С++ все очень хорошо. Выше уже написали про динамическую память. Я же добавлю, что семантика перемещений (С++11) позволяет создавать классы, описывающие регистры, прерывания, и прочее железо с очень читабельным и удобным синтаксисом. Посмотрите, например, github.com/den-makarov/stm32asyn
Это достаточно мощная С++11 библиотека (на базе HAL), которая в первую очередь предназначена для реализации фонового (через DMA) асинхронного ввода-вывода. Есть SPI, USART, ADC, SDIO. Единственное ограничение — она отлажена пока только на STM32F4. За счёт того, что все железо описывается и инициализируется в одном месте, поддерживается динамическая смена тактовой частоты контроллера. Есть очередь событий, которые генерируются по прерываниям. То есть асинхронные операции через DMA генерируют прерывания, они, в свою очередь, события, а основной поток уже занимается обработкой и диспетчеризацией событий. И все это на С++. Присоединяйтесь!
Это достаточно мощная С++11 библиотека (на базе HAL), которая в первую очередь предназначена для реализации фонового (через DMA) асинхронного ввода-вывода. Есть SPI, USART, ADC, SDIO. Единственное ограничение — она отлажена пока только на STM32F4. За счёт того, что все железо описывается и инициализируется в одном месте, поддерживается динамическая смена тактовой частоты контроллера. Есть очередь событий, которые генерируются по прерываниям. То есть асинхронные операции через DMA генерируют прерывания, они, в свою очередь, события, а основной поток уже занимается обработкой и диспетчеризацией событий. И все это на С++. Присоединяйтесь!
Прошу прощения за битую ссылку. Вот правильная: github.com/den-makarov/stm32async
Что мне не нравиться в Cube (прошу прощения за эмоции):
1. Если мне нужна только LL библиотека, всё равно получу смесь HAL и LL, даже если выбирал только LL.
2. Нет возможности выбрать только FreeRTOS без CMSIS RTOS API. (в CMSIS RTOS нет например streaming buffer)
3. При включении прерывания по UART, включаеться только NVIC, а для UART нужно вллючать вручную.
4. Нет возможности отказаться от Timebase Source. Если у меня RTOS и я получаю тик от SysTimer, ну нахрена мне в системе два таймера с прерыванием 1ms (от Timebase Source и SysTimer)
5. Cube генерирует Debug код с оптимизацией по размеру.
Знаю, что можно потом удалить ненужное.
1. Если мне нужна только LL библиотека, всё равно получу смесь HAL и LL, даже если выбирал только LL.
2. Нет возможности выбрать только FreeRTOS без CMSIS RTOS API. (в CMSIS RTOS нет например streaming buffer)
3. При включении прерывания по UART, включаеться только NVIC, а для UART нужно вллючать вручную.
4. Нет возможности отказаться от Timebase Source. Если у меня RTOS и я получаю тик от SysTimer, ну нахрена мне в системе два таймера с прерыванием 1ms (от Timebase Source и SysTimer)
5. Cube генерирует Debug код с оптимизацией по размеру.
Знаю, что можно потом удалить ненужное.
А про libopencm3 что скажете?
А мне в Кубе не нравится новый дизайн, особенно когда приходится работать на ноутбуке. Первый вариант был логичнее и удобнее.
STM32 fast start. Часть 3 Hello World на LL
А что под LL тут имеется ввиду?
«Программа прошивальщик (она же пригодится для полного стирания запоротого контроллера, подробнее о процедуре можно почитать ЗДЕСЬ).»
А куда это «ЗДЕСЬ» ведет — не рассказано.
А куда это «ЗДЕСЬ» ведет — не рассказано.
Не знаю пока, как именно вы собираетесь реализовывать Hello World, но ИМХО обмен несколькими символами с юзером — не лучшее средство тестирования средств разработки для MK. Чтобы можно было их сравнивать, следовало бы задействовать, как минимум, прерывания, таймеры и пару-тройку интерфейсов, например, USB, SPI и I2C. Вот тут-то и вылезло бы, к примеру, что для LL обработчик прерывания нужно полностью писать самому, а для HAL достаточно написать callback (который, однако, будет вызываться громоздким HAL-обработчиком).
Получилось помигать светодиодом на «голубой таблетке». У меня вопрос-пожелание автору: можно ли в следующих статьях обсудить вопрос о том, как размещать файлы проекта в GIT репозитории? В том же «stm32_hello_world» проекте куча файлов, но все ли их надо размещать под GIT-контроль?
Статья начиналась обсуждением вопросов быстроты разработки, тяжеловесности проектов и проч.
Это было реально интересно. И согласен на все 100 с автором, что все спорщики по своему правы. Просто надо применять под свои требования свои принципы (библиотеки) разработки.
А две трети статьи — это реально нормальный туториал. Мне кажется в одной статье автор постарался вместить две и решить две проблематики. Я бы разбил на разные ветви.
Но в целом респек за непредвзятый взгляд!
Это было реально интересно. И согласен на все 100 с автором, что все спорщики по своему правы. Просто надо применять под свои требования свои принципы (библиотеки) разработки.
А две трети статьи — это реально нормальный туториал. Мне кажется в одной статье автор постарался вместить две и решить две проблематики. Я бы разбил на разные ветви.
Но в целом респек за непредвзятый взгляд!
Ну с такой скоростью выпуска остальных частей ST успеет заменить нас ИИ и курс станет не актуальным
Ну когда же продолжение сериала!? Интересно же что будет дальше!
Кубик — это конечно хорошо, сам использовал для быстрого запуска макета. А потом обновил кубик и пересобрал проект т.к. изменил назначение выводов. И генератор на внешнем кварце перестал работать, только внутренний. И не работал до следующего обновления кубика. Это к тому что ошибки в генерируемом коде есть и искать их иногда очень затратно по времени т.к. надеешься что «уж там то все не раз проверили» и в первую очередь шерстишь свой код.
Кубик — это конечно хорошо, сам использовал для быстрого запуска макета. А потом обновил кубик и пересобрал проект т.к. изменил назначение выводов. И генератор на внешнем кварце перестал работать, только внутренний. И не работал до следующего обновления кубика. Это к тому что ошибки в генерируемом коде есть и искать их иногда очень затратно по времени т.к. надеешься что «уж там то все не раз проверили» и в первую очередь шерстишь свой код.
Мне статья очень помогла, спасибо!
Жду не дождусь ВТОРОЙ части!!!
Очень доходчиво и главное интересно. В планах не было изучения STM32, после прочтения сразу заказал на алиэкспресс STM32F103C8T6, ST LINK V2 был куплен ранее.
Очень бы хотелось в второй части прочесть «ликбез» о линейке STM32, в плане домашнего/хоббийного применения на что ещё в линейке стоит обратить внимание.
Очень доходчиво и главное интересно. В планах не было изучения STM32, после прочтения сразу заказал на алиэкспресс STM32F103C8T6, ST LINK V2 был куплен ранее.
Очень бы хотелось в второй части прочесть «ликбез» о линейке STM32, в плане домашнего/хоббийного применения на что ещё в линейке стоит обратить внимание.
Очень много по STM32 и не только есть на сайте narodstream.ru
С такой скоростью выдачи автором продолжений, вам снова расхочется изучать STM32. Или как тут советуют на народстрим идти. Хотя там как то автор непоследователен весьма, прыгает то CMSIS, то HAL, то блюпил, то нуклео…
Попробуйте еще libopencm3. Тут написали очень полезный шелл-скрипт для быстрого старта:
# Start a new libopencm3 based project for Blue Pill STM32F103C8 board.
# Takes project name as a parameter.
Автор, как мягко вы обошли систему тактирования и тот факт, что процессор запустился на частоте 8мгц, вместо положенных 72 и на внутреннем кварце, а не внешнем, распаянном на плате.
В новой версии куба HSE почему-то не выбирается.
UPD: необходимо в разделе RCC сказать источник тактирования… Дебильнейший новый интерфейс куба сбивает с толку.
Считаю, что данная статья нацелена больше на показ как собрать первый проект. Про систему тактирования STM можно написать отдельную серию статей, особенно если расписывать в каком случае какой источник лучше применить.
Старт оказался сразу финишем…
Sign up to leave a comment.
STM32 fast start. Часть 1 ПО, материалы, Cube MX