Комментарии 30
Ээээ, а зачем танцы с бубном и VSCode, когда можно работать прямо в VisualStudio с VisualGDB?..
Спасибо, есть пара интересностей, но столько утилит и фреймворков чтоб светодиодом комфортнее помигать....
Куб и так генерирует мейкфайл, которому достаточно указать путь для gcc в tasks.json , хотелось бы увидеть пример кода или проекта, где имеет смысл наворачивать столько фарша помимо мейка. Или щас в ойти прям увольняют пожизненно, если не дай бох руками мейкфайл править?
Не понял про увольнение.
Я пробовал собирать и мейкфайлом из кубика в том числе. Никаких проблем с этим не было.
Насчёт фарша - тут из отличий от "обычного" проекта только cmake. Естественно, он не обязателен для отладки в VSCode, однако он даёт определённый набор преимуществ в плане подключения библиотек и автонастройки расширения c/c++
Ничем обидеть не хотел, просто очень часто слышу мол использование чистого make это плохой подход старых дедов и вообще плохо плохо как goto. Просто при этом не приводятся примеры проектов на на bare metall где наворачивание cmake оправдано.
Ничего против make в чистом виде не имею, но если и пушка и ядра бесплатные, то почему бы не использовать то, что даёт больше возможностей.
Однако я могу привести пример (пусть и только в виде описания). В одном из проектов у меня есть несколько очень похожих по структуре и функционалу устройств. Бо́льшая часть кода у них одинаковая, различие лишь в одном файле - парсере команд. При использовании CMake я могу держать парсер обоих устройств в одном проекте и собирать сразу два исполняемых файла без дублирования кода.
В упомянутых в статье видео EbeddedGeek показаны настройки VSCode для работы с чистым Makefile. Также в рунете есть статья по модификации его для совместной компиляции c и cpp файлов.
В целом, всё неплохо, кубик не удаляет и не переписывает пользовательские строки в мейкфайле(только что проверил), однако нужно настраивать c_cpp_properties и launch ручками и искать svd файл(что тоже не проблема, в целом, так как это делается один раз при создании проекта).
И ещё небольшая поправка к первому вашему комментарию: сейчас установщик ARM GNU Toolchain прописывает путь до компилятора в $Path так что достаточно написать имя компилятора.
Если задача только собрать проект (и тесты, например, запустить), то cmake скрывает необходимость установки фреймворков, так как умеет с github-а подтянуть, остается лишь компилятор поставить.
Для VsCode и STM32 есть плагин PlatfromIO, по факту бесплатный аналог VisualGDB, о котором говорили выше. Но PlatfromIO по моему мнению обладает куда большим функционалом, статический анализатор, анализ использованной памяти, удаленная отладка через tcp/ip, запуск Unit тестов, как на мк так и нативно на ПК (только аппаратно-независимый код).
В PlatformIO платная отладка. Статический анализатор есть и без него, кстати. Он появляется при подключении пакета расширений C/C++
Только удаленная отладка платная, локально все хорошо (что логично ведь это простой openocd). Единственное, что пока в Platformio напрягает - это несвежесть компилятора, что решается путем скачивания и замены файлов в одной директории.
P.S. Чтобы два раза не вставать: использованный ObKo/stm32-cmake нормально из коробки подгружает библиотеки при их отсутствии? Мне не удалось, пришлось править в одном месте явный вызов MakeAvailable подставить.
Что имеется в виду под отсутствием?
Отсутствие в папке проекта? Я в своём примере их и так не включал. Я проверил его работу на двух семействах - F1 и F4, пока проблем не было, всё скачивалось.
Если же вопрос про отсутствие библиотек в репозитории, откуда он их подгружает, то тут не могу ничего сказать.
Не могу назвать себя спецом в cmake, но насколько понял из исходников, сценарий там такой примерно:
Если указаны STM32_CUBE_${FAMILY}_PATH или STM32_CMSIS_${FAMILY}_PATH, то взять оттуда.
Если не указаны, то считать, что кубовские библиотеки лежат по пути /opt/STM32Cube${FAMILY}
В utilities.cmake есть функции stm32_fetch_XXX, подтягивающие CMSIS/HAL с github, но я так и не нашел, где они вызываются и вставил руками.
Вопрос такой в итоге: без установленных заранее CMSIS/HAL у вас всё нормально собралось?
Понял.
Для проверки я удалил репозиторий CubeMX из системы, однако отмечу, что, как можно увидеть в CMakeLists, переменные эти у меня не объявлены. Папки /opt/ в Windows тоже нет.
Результат такой: в момент конфигурации у меня ненадолго возрастает до максимума нагрузка на сеть, если подпапка /build отсутствует в проекте. Данные подтягиваются, проект собирается.
Перепроверил. Похоже, что я неправ – и отладка, и весь IDE в целом бесплатны.
Меня смутили некоторые особенности его работы, однако в остальном - прекрасный инструмент
По своему опыту понял, что для меня пока что ничего кроме Keil не подходит под серьёзные проекты, даже допотопность Keil нивелируется компилятором, в сравнении с ARM Compiler 6 все конкурирующие компиляторы проигрывают, это начинаешь понимать только когда проект большой и сложный, когда вопрос памяти и скорости работы стоит во главе угла. Пробовал связку VS code + Embedded IDE (https://em-ide.com/) с подключением ARM Compiler, но всё равно есть проблемы со скоростью отладки, хотя как у редактора кода у VS code нет конкурентов сейчас.
Я сравнил объем кода, генерируемого armclang v6.17 (из кейла 5.38а самого последнего) и arm-none-eabi-gcc в тулчейне с newlib nano.
И тут такой момент: при оптимизации с флагом -O0 действительно код из кейла меньше где-то на 0.7 КБ, однако при оптимизации -Oz + LTO код из кейла оказывается больше тоже почти на килобайт.
Скорость работы я не проверял, надо собрать оба варианта с -Os и запустить какой-нибудь алгоритм достаточно сложный
вы сейчас сравниваете LLVM (ака clang) и GCC, отсюда и разница в объемах результирующего кода. Для интереса, сравните выхлоп 5 версии компилятора (он на основе gcc как раз) с arm-none-eabi-gcc. Разница должна быть минимальной в таком кейсе.
хотя кейлы как раз 6 версию своего компилятора активно продвигают по типу он "быстрее\компактней"
ARM сейчас вообще кейл поддерживают просто потому что, а продвигают они свою Web IDE.
Да, действительно, я сравниваю два разных по принципу алгоритма, однако именно в этом и суть. Зачем сравнивать одинаковое?
Изначально в моём ответе был упомянут и ARMCC, главная проблема которого в том, что он очень очень очень медленно работает. Ну и ещё он не поддерживает даже c++11, как я понял по опыту. Но прошивки на его выходе получаются действительно компактными. Возможно, за счёт того, что код, который он всё же может обработать, это си и си с классами.
если я правильно помню, адекватная поддержка С++ у кейла появилась именно в armclang.
Да, действительно, я сравниваю два разных по принципу алгоритма, однако именно в этом и суть. Зачем сравнивать одинаковое?
из текста показалось что сравниваете проприетарный компилятор и свободно распространяемый. в данном случае имело смысл сравнивать одинаковое. Теперь когда стало понятно что сравнение именно технологий, то да.
Изначально в моём ответе был упомянут и ARMCC, главная проблема которого в том, что он очень очень очень медленно работает
Давно ушел от кейла, однако пробовал решение от Segger (их собственная сборка на основе armclang) которое выдает более компактную прошивку, по сравнению с тем же gcc. Разница на одном и том же проекте составила более 2кБ. Основное отличие при просмотре ассемблерного кода (у меня по крайней мере) в использовании одной инструкции вместо двух при загрузке int32 в регистры, однако скорости это не добавляет, так как инструкция все равно выполняется за 2 такта.
Почему два такта? У Cortex-M 32битное АЛУ, но 16 битная шина?
Хороший вопрос, не задумывался. Исходил из описания инструкций отсюда:
Заметил что по ассемблеру инструкций меньше, а счетчик тактов инкрементируется одинаково. Надо у Дзозефа Ю почитать за этот момент
Про какие команды речь? Судя по тому, что написано в референсе по ссылке, все Load/Store команды выполняются не меньше двух тактов. Полагаю, что segger используют другие флаги для компилятора, и оптимизируют где-то ещё.
оптимизация одинаковая стоит.
GCC выдавал две инструкции (не помню какие именно, возможно использовался MOV два раза, что эквивалентно одному LDR), а CLANG - одну.
По тактам время исполнения получилось одинаковым. Кода получаем меньше (число инструкций то другое), а время исполнения при этом не меняется.
Будет пауза на работе, попробую повторить эксперимент
Кстати и сам clang нормально собирает под arm bare metal, только нужно ему библиотеки сишные подсунуть во время линковки хоть даже от гцц или же собрать себе из исходников ллвмные.
Ну я в VSCode недавно перещел полностью, как IAR выпустил официальное расширение под VS Code, нажал 2 кнопки и работаешь преспокойно, только запарится с настройкой проекта в самом IAR
У меня был опыт stm32 и Attolic True Studio (Eclipse) под Виндоус. Все бесплатно получается, отладка есть, если кому интересно. Помню поднял USB и USB Rndis web server без проблем.
Прошивка и отладка STM32 в VSCode под Windows