Тем не менее, насколько мне известно, Keil и IAR остаются самыми распространенными инструментами для программирования МК, и их компиляторы поддерживают максимум cpp14 (хотя вообще у armclang из кейла есть community поддержка gnu++17)
Про какие команды речь? Судя по тому, что написано в референсе по ссылке, все Load/Store команды выполняются не меньше двух тактов. Полагаю, что segger используют другие флаги для компилятора, и оптимизируют где-то ещё.
ARM сейчас вообще кейл поддерживают просто потому что, а продвигают они свою Web IDE.
Да, действительно, я сравниваю два разных по принципу алгоритма, однако именно в этом и суть. Зачем сравнивать одинаковое?
Изначально в моём ответе был упомянут и ARMCC, главная проблема которого в том, что он очень очень очень медленно работает. Ну и ещё он не поддерживает даже c++11, как я понял по опыту. Но прошивки на его выходе получаются действительно компактными. Возможно, за счёт того, что код, который он всё же может обработать, это си и си с классами.
Я сравнил объем кода, генерируемого armclang v6.17 (из кейла 5.38а самого последнего) и arm-none-eabi-gcc в тулчейне с newlib nano.
И тут такой момент: при оптимизации с флагом -O0 действительно код из кейла меньше где-то на 0.7 КБ, однако при оптимизации -Oz + LTO код из кейла оказывается больше тоже почти на килобайт.
Скорость работы я не проверял, надо собрать оба варианта с -Os и запустить какой-нибудь алгоритм достаточно сложный
Ничего против make в чистом виде не имею, но если и пушка и ядра бесплатные, то почему бы не использовать то, что даёт больше возможностей.
Однако я могу привести пример (пусть и только в виде описания). В одном из проектов у меня есть несколько очень похожих по структуре и функционалу устройств. Бо́льшая часть кода у них одинаковая, различие лишь в одном файле - парсере команд. При использовании CMake я могу держать парсер обоих устройств в одном проекте и собирать сразу два исполняемых файла без дублирования кода.
В упомянутых в статье видео EbeddedGeek показаны настройки VSCode для работы с чистым Makefile. Также в рунете есть статья по модификации его для совместной компиляции c и cpp файлов. В целом, всё неплохо, кубик не удаляет и не переписывает пользовательские строки в мейкфайле(только что проверил), однако нужно настраивать c_cpp_properties и launch ручками и искать svd файл(что тоже не проблема, в целом, так как это делается один раз при создании проекта).
И ещё небольшая поправка к первому вашему комментарию: сейчас установщик ARM GNU Toolchain прописывает путь до компилятора в $Path так что достаточно написать имя компилятора.
Понял. Для проверки я удалил репозиторий CubeMX из системы, однако отмечу, что, как можно увидеть в CMakeLists, переменные эти у меня не объявлены. Папки /opt/ в Windows тоже нет.
Результат такой: в момент конфигурации у меня ненадолго возрастает до максимума нагрузка на сеть, если подпапка /build отсутствует в проекте. Данные подтягиваются, проект собирается.
Что имеется в виду под отсутствием? Отсутствие в папке проекта? Я в своём примере их и так не включал. Я проверил его работу на двух семействах - F1 и F4, пока проблем не было, всё скачивалось.
Если же вопрос про отсутствие библиотек в репозитории, откуда он их подгружает, то тут не могу ничего сказать.
Я пробовал собирать и мейкфайлом из кубика в том числе. Никаких проблем с этим не было.
Насчёт фарша - тут из отличий от "обычного" проекта только cmake. Естественно, он не обязателен для отладки в VSCode, однако он даёт определённый набор преимуществ в плане подключения библиотек и автонастройки расширения c/c++
Соберите в кучу ряд своих претензий и поговорите с преподавателями о том, что можно было бы изменить, добавить и т.д. Если есть та практика, которая бы пригодилась и которую можно добавить в программу - предложите её, возможно что-то и поменяется. Им это тоже выгодно в конце-концов. Подлкючите свое руководство, подключите руководство ВУЗов. Скажите им, что это принесёт больше денег, и они будут рады, хд
Тем не менее, насколько мне известно, Keil и IAR остаются самыми распространенными инструментами для программирования МК, и их компиляторы поддерживают максимум cpp14 (хотя вообще у armclang из кейла есть community поддержка gnu++17)
Я так полагаю в контексте Cortex-M ядер?
Сейчас это всё называется STM32 CubeIDE.
Эклипс, всё же, не такой удобный как вскод, на мой вкус.
Ну да, транслятор из IR кода LLVM в ARM уже есть давно.
В общем-то говоря, можно использовать тот метод компиляции, которые считаете удобным. На процесс отладки это в большинстве случаев не влияет.
Про какие команды речь? Судя по тому, что написано в референсе по ссылке, все Load/Store команды выполняются не меньше двух тактов. Полагаю, что segger используют другие флаги для компилятора, и оптимизируют где-то ещё.
Почему два такта? У Cortex-M 32битное АЛУ, но 16 битная шина?
ARM сейчас вообще кейл поддерживают просто потому что, а продвигают они свою Web IDE.
Да, действительно, я сравниваю два разных по принципу алгоритма, однако именно в этом и суть. Зачем сравнивать одинаковое?
Изначально в моём ответе был упомянут и ARMCC, главная проблема которого в том, что он очень очень очень медленно работает. Ну и ещё он не поддерживает даже c++11, как я понял по опыту. Но прошивки на его выходе получаются действительно компактными. Возможно, за счёт того, что код, который он всё же может обработать, это си и си с классами.
Я сравнил объем кода, генерируемого armclang v6.17 (из кейла 5.38а самого последнего) и arm-none-eabi-gcc в тулчейне с newlib nano.
И тут такой момент: при оптимизации с флагом -O0 действительно код из кейла меньше где-то на 0.7 КБ, однако при оптимизации -Oz + LTO код из кейла оказывается больше тоже почти на килобайт.
Скорость работы я не проверял, надо собрать оба варианта с -Os и запустить какой-нибудь алгоритм достаточно сложный
Ничего против make в чистом виде не имею, но если и пушка и ядра бесплатные, то почему бы не использовать то, что даёт больше возможностей.
Однако я могу привести пример (пусть и только в виде описания). В одном из проектов у меня есть несколько очень похожих по структуре и функционалу устройств. Бо́льшая часть кода у них одинаковая, различие лишь в одном файле - парсере команд. При использовании CMake я могу держать парсер обоих устройств в одном проекте и собирать сразу два исполняемых файла без дублирования кода.
В упомянутых в статье видео EbeddedGeek показаны настройки VSCode для работы с чистым Makefile. Также в рунете есть статья по модификации его для совместной компиляции c и cpp файлов.
В целом, всё неплохо, кубик не удаляет и не переписывает пользовательские строки в мейкфайле(только что проверил), однако нужно настраивать c_cpp_properties и launch ручками и искать svd файл(что тоже не проблема, в целом, так как это делается один раз при создании проекта).
И ещё небольшая поправка к первому вашему комментарию: сейчас установщик ARM GNU Toolchain прописывает путь до компилятора в
$Pathтак что достаточно написать имя компилятора.Понял.
Для проверки я удалил репозиторий CubeMX из системы, однако отмечу, что, как можно увидеть в CMakeLists, переменные эти у меня не объявлены. Папки
/opt/в Windows тоже нет.Результат такой: в момент конфигурации у меня ненадолго возрастает до максимума нагрузка на сеть, если подпапка
/buildотсутствует в проекте. Данные подтягиваются, проект собирается.Что имеется в виду под отсутствием?
Отсутствие в папке проекта? Я в своём примере их и так не включал. Я проверил его работу на двух семействах - F1 и F4, пока проблем не было, всё скачивалось.
Если же вопрос про отсутствие библиотек в репозитории, откуда он их подгружает, то тут не могу ничего сказать.
Перепроверил. Похоже, что я неправ – и отладка, и весь IDE в целом бесплатны.
Меня смутили некоторые особенности его работы, однако в остальном - прекрасный инструмент
В PlatformIO платная отладка. Статический анализатор есть и без него, кстати. Он появляется при подключении пакета расширений C/C++
Не понял про увольнение.
Я пробовал собирать и мейкфайлом из кубика в том числе. Никаких проблем с этим не было.
Насчёт фарша - тут из отличий от "обычного" проекта только cmake. Естественно, он не обязателен для отладки в VSCode, однако он даёт определённый набор преимуществ в плане подключения библиотек и автонастройки расширения c/c++
Кроме того, VSCode весит сильно меньше Visual Studio и имеет довольно много приятностей из расширений.
Соберите в кучу ряд своих претензий и поговорите с преподавателями о том, что можно было бы изменить, добавить и т.д. Если есть та практика, которая бы пригодилась и которую можно добавить в программу - предложите её, возможно что-то и поменяется. Им это тоже выгодно в конце-концов. Подлкючите свое руководство, подключите руководство ВУЗов. Скажите им, что это принесёт больше денег, и они будут рады, хд
В таком случае я ошибся. Думал, что у арм лицензия ограничена по времени действия.
а как же у хуеавей отобрали?
Я, скорее, имел в виду, что "--" — это способ поставить длинное тире (или дефис, нинаю) в ТеХ и вроде в маркдауне.