Comments 47
Очередной туториал по Eclipse с make в 2022? Остановите планету, я сойду.
Автору рекомендую открыть для себя человеческие инструменты и отправить наконец эклипс в мусорное ведро на пенсию, где ему и место. Поиск замены можно начать с CLion или VSCode.
Эклипс просто неюзабелен по современным меркам. Парсер C++ ломается на всем, что сложнее хеллоуворлда; интеграция отладчика с GDB ломается через раз сама по себе; интеграции с системами контроля версий практически отсутствуют; автодополнение ломается вместе с парсером языка, а если парсер и работает, предложенный функционал абсолютно минимален; нет языковых инъекций и встроенной поддержки других языков, используемых в проекте, вроде питона (только не начинайте про PyDev); нет нативной поддержки современными утилитами (как насчёт CoPilot?). Автоматические рефакторинги C++ там такие, что лучше бы их не было. Список не полный, конечно, я последний раз им пользовался лет пять назад и с тех пор не оглядывался ни разу.
Эклипс был хорош 10-15 лет назад на фоне отсутствия альтернатив. Сегодня его можно советовать для новых проектов только от незнания современных инструментов.
В профессии программист МК, как в деревне ничего не меняется десятилетиями. Постоянный консерватизм в наборе технологий. Что в 2011 в военном НИИ программировали Cortex-M3 в IAR на C с классами так и в 2021 в Яндекс.Драйв программируют Cortex-M3 в IAR на С c классами.
как в деревне ничего не меняется
Чтож, ну давайте доедать кактус тогда, раз перемены запрещены.
CLion стоит $238.80=12619,95 RUR.
В типичной российской организации нереально выпросить бюджет на покупку какого-то непонятного платного софта, если есть бесплатная и в обoем-то неплохая альтернатива.
В BackEnd Яндекс.Драйв вообще пользуются Vim и их это более чем устаивает.
Очередной туториал по make в 2022?
Пуговицы изобрели вообще в средневековье. Однако ими по сей день пользуются аж 2022году. Может пояcните почему?
VS code очень многих раздражает.
Вот что писал человек, который однажды пытался работать в VS code
"Ну, для начала мне не нравится, что VScode после установки почему-то отжирает почти полгига места на диске, при том что это, по сути, текстовый редактор. Не знаю как сейчас, но когда я последний раз его ставил, мне пришлось ещё накинуть в систему какую-то там версию .Net просто потому что она очень нужна была этой печатной машинке. Мне также не нравится, что этот текстовый редактор VScode независимо от того что я думаю на сей счет, со всех сил пытается быть IDE, даже там где это совершенно не нужно.
Но больше всего меня раздражает, что при всём желании этого текстонабирателя быть полноценной IDE, для того чтобы в нём были все необходимые IDE функции, в любом случае придётся ставить плагины, разумеется сторонние. А после установки плагинов оно начинает гораздо чаще глючить и медленно работать..."
У VS Code плохие отзывы, рецензии. Много рекламаций.
Посоветуйте вашему человеку дышать глубже и подбирать инструменты сообразно задаче. Если нужен текстонабиратель, есть nano/vi/notepad.exe. Если нужна IDE, придётся повозиться и пожертвовать парой гигабайт места на диске как минимум (почему это вообще проблема? у него место на диске платное?). Приведённая критика выглядит неадекватно и как-то эмоционально.
Вообще, пользуясь случаем, хочу бросить большой камень всем C++ IDE в принципе, и в этом поддержать вашего горячего знакомого конкретно в части "начинает гораздо чаще глючить и медленно работать". Даже топовые CLion и основанный на clang плагин C++ для VSCode регулярно ломаются в сложных проектах: то индекс слетит, то миспарсинг, то "Resolving symbol..." подвисает на минуту на ровном месте, то авторефакторинг калечит код так что приходится системой контроля версий его откатывать, и т.п. Знающие люди винят избыточность языка, что делает сложность разработки инструментария непомерно высокой (тем более с учётом постоянно развивающегося стандарта). Я сам давно бы завязал с C++ и перешёл на технологии поновее, но легаси всё не отпускает.
У VS Code плохие отзывы, рецензии. Много рекламаций.
То ли дело эклипс, да?
Это точно не перевод какой-нибудь статьи пятилетней давности?
Брать голый эклипс и что-то там настраивать и при этом рекомендовать доставать сервер деббагера из Attolic true studio, который сам по себе был IDE для написания кода для STM32? Что вообще происходит? Есть же уже несколько лет STM32CubeIDE на базе того же эклипса, где уже всё настроено.
Использовать компилятор 8ми летней выдержки - это чем-то обосновано?
Нынешние IDE это уже целые экосистемы. Они не сводятся к редактору или компилятору
Keil стоит попробовать хотя бы только для того чтобы увидеть сколько софта можно позаимствовать не изобретая велосипедов.
STM32CubeMX в этом плане сильно отстаёт.
Те же add-on для RTOS в IAR или timeline на порядок повышают эффективность отладки.
Про подключение конфигурирование проектов для IAR тоже некорректно сказано. Проект IAR хранится в формате XML и также легко переделывается как и make файлы, даже легче.
Не стоило автору противопоставлять тулсы, их надо применять все и из каждого брать лучшее.
Вот вам WarStory.
Вы программируете в IAR.
У вас 53 конфигурации. Все в одном файле workspace *.ewp в 55k строк кода.
И тут вам надо из всех сборок исключить 3 *.с файлика, а также макросы препроцессора и пути к заголовочным файлам для них.
В IDE у вас рука отвалится мышку водить. Да и переносить 150 строк в ноду <excluded> тоже задолбает уже на третей сборке. А останется еще 50 сборок обработать.
У вас на это уйдет весь день.
В make файле это делается одной строчкой или даже одним символом.
Ваш сценарий описывает довольно неудобный воркфлоу (рабочий процесс).
Во первых, нельзя допускать у себя 53 конфигурации.
Я в таких случаях переношу выбор конфигураций в рунтайм.
Но никогда не допускаю больше нескольких конфигураций.
Тоже про макросы препроцессора. По своей воле стараюсь не создавать таких. Если они приходят из сторонних сорсов также рефакторю чтобы их стало меньше.
А далее запускаю скрипт питона (у вас питон есть в списке необходимого, значит владеете им) и генерируется workspace по шаблону.
Тэг <excluded> не использую, чтобы не захламлять тот же воркспейс.
Есть чистый код, но чистый и обозреваемый воркспейс тоже очень важен.
В make файлах удобнее. Там управление модульностью заложена разработчиками. IAR это для прототипирования единичных сборок или для обучения синтаксису программирования в ВУЗ(ах).
Для промышленного программирования надо пользоваться make.
Тут вы смешиваете систему сборки и собственно управление сорсами.
В IAR более продвинутая чем make система сборки - Ninja
Она и с эклипсами идет, но только в IAR гораздо более мощный отладчик в паре с Segger Ultra адаптером.
Странно что вы столько внимания уделяете сборке, когда наибольшее время занимает отладка. И эффективность отладки самый важный критерий выбора среды.
Для отладки достаточно интерфейса командной строки CLI поверх UART.
(см как в FlipperZero).
Куда важнее управление модульностью и сотнями сборок.
GDB нужен максимум для отладки UART. Далее в ход вступает UART-CLI(шка)
CLI-са в принципе не поможет отладить алгоритмы фильтрации, детекции, PID и прочие алгоритмы в реальном времени. Тут нужны более мощные тулсы:
Т.е. CLI-са очень и очень ограниченный инструмент. Хотя да, на начальном этапе или в неполностью контролируемой среде (например во время реверса) вполне годный.
наибольшее время занимает отладка
Я бы сказал, что наибольшее время занимает написание тестов для верификации, но, возможно, это варьируется в зависимости от методологии.
Во первых, нельзя допускать у себя 53 конфигурации
Расскажите это Яндекс.Драйв(у).
В чем то отстает, в чем то опережает... Мне вот например в cubeIDE нравится количество инструментов для работы с SWV. KEIL во многих отношениях просто кардинально проще и обделен полезными инструментами, которые есть, что в кубе, что в атолике. Одно мне в кейле понравилось - есть поддержка "живых" переменных для ст-линка. А редактор текстовый в кейле - позапрошлый век.
Спасибо за статью! Достойной информации на русском не много. А по сути у меня впечатление что "хрен редьки не слаще". Производители всяких микроконтроллеров и сред разработки всё пытаются нам "помочь", упростить жизнь. Что бы легче программировать. А по факту получается всё хуже и сложнее.
В самом свежем SDK от нордика остался только VS Code, видать от Segger Embedded Studio отказались. Лично я срача Eclipse vs VS Code не понимаю, и там и там куча своих проблем. И у IAR своих куча. У Keil наверняка тоже своих заморочек полно
Есть еще интересный плагин для Visual Studio - VisualGDB, он под embedded, но платный. На всем известном ресурсе есть вылеченные версии
Интересно, а почему бы не взять гцц еще старее?
На сайте
https://launchpad.net/gcc-arm-embedded/+download
самая свежая версия компилятора GCC для ARM 2016-09-28
Да ладно, а вы посмотрите в другом месте
https://developer.arm.com/downloads/-/gnu-rm
Я ни на что не намекаю, но может нужно в более надежных источниках софт искать?
Настройка ToolChain(а) для Win10+GCC+С+Makefile+ARM Cortex-Mx+GDB