Пролог
В программировании микроконтроллеров часто Eclipse с плагинами используют потому что в нем есть плагины, которые генерируют make файлы для сборки программ на Си, согласно разметке проекта в XML под названием .cproject и .project.
Эти плагины были сделаны, главным образом, для того, чтобы вовлечь в процесс программирования микроконтроллеров школьников и прочих специалистов без профильного IT образования и опыта в области Computer Science. Понимаете?
Далее я напишу почему сборка с Eclipse плагинами для IDE не годится для промышленного программирования.
Теория сборки Си программ в IDE c плагинами
По сути, построение любого Cи-кода в IDE сводится к трем простым, но очень частым действиям
Добавить мышкой исходник к проекту
Добавить мышкой пути к папкам с кодом
Добавить мышкой макросы препроцессора к проекту
Всё это сваливается в файл .cproject. Этот файл .cproject — это авто‑генеренный файл, в который руками лучше не соваться. Ибо если Вы случайно там что‑то поменяете и сохраните, то в один утренний день у Вас просто не откроется проект! Далее Вас начнется приступ судороги, конвульсии и паралич. Нормально так да?... Это проблема номер 1.
Проблема №2: Ручное Прописывание Путей
Это вообще самая больная тема при сборке при IDE c плагинами.
При сборке из-под IDE вам всегда придется вручную мышкой в настройках IDE прописывать пути к программным компонентам и к заголовочным файлам
"${workspace_loc:/${ProjName}/control/system}"
"${workspace_loc:/${ProjName}/control}"
Но есть один трюк. Он заключается в том, чтобы прописывать пути в переменную окружения INCDIR и скормить её в IDE. Можно написать *.bat скрипт.
@echo off
cls
echo INCDIR=[%INCDIR%]
set PROJECT_LOC=%cd%
echo PROJECT_LOC=[%PROJECT_LOC%]
set "PROJECT_LOC=%PROJECT_LOC:\=/%"
echo PROJECT_LOC=[%PROJECT_LOC%]
echo WORKSPACE_LOC=[%PROJECT_LOC%]
set WORKSPACE_LOC=%PROJECT_LOC%/../..
echo WORKSPACE_LOC=[%WORKSPACE_LOC%]
set INC_DIR=-I"%WORKSPACE_LOC%/control/task"
set INC_DIR=%INC_DIR% -I"%WORKSPACE_LOC%/adt/fifo"
set INC_DIR=%INC_DIR% -I"%WORKSPACE_LOC%/control/system"
set INC_DIR=%INC_DIR% -I"%WORKSPACE_LOC%/adt"
set INC_DIR=%INC_DIR% -I"%WORKSPACE_LOC%/boards"
set INC_DIR=%INC_DIR% -I"%WORKSPACE_LOC%/adt/array"
set "INC_DIR=%INC_DIR:\=/%"
echo INC_DIR=[%INC_DIR%]
setx INCDIR "%INC_DIR%"
echo INCDIR=[%INCDIR%]
pause
Этот скрипт надо отработать до запуска Eclipse. Тут очень важно чтобы черточка была именно такая "/" . Иначе система сборки не распознает этот путь. Далее надо прописать make переменную ${INCDIR} вот тут
Однако и тут всё не так гладко. Максимальная длина переменной окружения в cmd всего 8192 символа. А сохранить setx(ом) между сессиями можно и вовсе всего только 1024 символа в одной переменной окружения. Понимаете? Вот и получается, что так можно прописать только очень мало путей. Остальное вручную мышкой пока не заноет запястье.
Проблема №3: Ручное прописывание макро определений для препроцессора
Вторая беда Eclipse IDE c ARM плагинами - это ручное прописывание макросов препроцессора. Макросы прописываются вот тут Properties → C/C++ Builds → Settings → Tool Settings → GNU Arm Cross C Compiler → Preprocessor → Define Symbol (-D)
тут в GUI окне Вы тоже мышкой добавляете и прописываете свои макросы один за другим, пока не заболит рука. Потом нажимаете Apply and Close. Но есть один трюк.
*Продвинутый способ передачи макроопределений
Однако можно передать файл extra_config.h
с макросами
#ifndef EXTRA_CONFIG_H
#define EXTRA_CONFIG_H
/* gcc -include extra_config.h -c *.o */
#define HAS_ADT
#define HAS_ARRAY
#define HAS_BOARD
#define HAS_CLI
#define HAS_CLI_NATIVE_COMMANDS
#define HAS_CLI_PROC
#define HAS_CLOCK
#define HAS_COMPUTING
#define HAS_COMPUTING_COMMANDS
#define HAS_CONNECTIVITY
#define HAS_CONNECTIVITY_COMMANDS
#define HAS_CONTROL
#define HAS_CONTROL_COMMANDS
#define HAS_CONTROL_COMMANDS
#define HAS_CUSTOM_PRINTF
#define HAS_DIAG
#define HAS_EXTRA_CONFIG
#define HAS_FIFO
#define HAS_FIFO_CHAR
#define HAS_FIFO_INDEX
#define HAS_FLASH
#define HAS_FLASH_DIAG
#define HAS_FLOAT_UTILS
#define HAS_FREE_RTOS
#define HAS_FREE_RTOS_COMMANDS
#define HAS_GENERIC
#define HAS_GENERIC_COMMANDS
#define HAS_GENERIC_MONOLITHIC
#define HAS_GENERIC_PROC
#define HAS_GPIO
#define HAS_GPIO_COMMANDS
#define HAS_GPIO_CUSTOM
#define HAS_GPIO_DIAG
#define HAS_INTERRUPT
#define HAS_LIMITER
#define HAS_LOG
#define HAS_LOG_COLOR
#define HAS_LOG_COMMANDS
#define HAS_LOG_DIAG
#define HAS_LOG_TIME_STAMP
#define HAS_MATH
#define HAS_MCAL
#define HAS_MCAL_COMMANDS
#define HAS_MICROCONTROLLER
#define HAS_NUM_DIAG
#define HAS_PARSE_8BIT_TYPES
#define HAS_PINS
#define HAS_PROTOCOLS
#define HAS_PROTOCOLS_COMMANDS
#define HAS_SCHEDULER
#define HAS_SENSITIVITY
#define HAS_SENSITIVITY_COMMANDS
#define HAS_STREAM
#define HAS_STRING
#define HAS_SUPER_CYCLE
#define HAS_SUPER_CYCLE_COMMANDS
#define HAS_SUPER_CYCLE_DIAG
#define HAS_SYSTEM
#define HAS_SYS_INIT
#define HAS_TASK
#define HAS_TASK_COMMANDS
#define HAS_TASK_DIAG
#define HAS_TIME
#define HAS_TIMER
#define HAS_TIMER5
#define HAS_TIME_PROC
#define HAS_UART
#define HAS_UART6
#define HAS_UART_CUSTOM
#endif /* EXTRA_CONFIG_H */
Далее опцией -include
прописав строчку -include extra_config.h
в настройках компилятора.
Как видно в логе сборки, макросы передаются успешно извне:
Таким образом Вы сэкономите неделю времени!
Сборка проекта
Сборку можно инициировать мышкой или горячей клавишей Ctrl+B
или тоже мышкой из IDE. Однако очень мало кто знает что можно также инициировать сборку и из консоли! Для начала кcли у Вас на PC нет прав администратора, чтобы изменить переменную PATH, то можете каждый раз изменять переменную PATH из консоли Windows cmd вот так
set PATH=%PATH%;C:\eclipse
set PATH=%PATH%;C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin
set PATH=%PATH%;C:\Artery_ATLINK_Console_Win32-x86_64_V3.0.08
set PATH=%PATH%;C:\OpenOCD_Artery\bin
set OPEN_OCD_PATH=C:\OpenOCD_Artery
После этого можно смело запускать скрипт сборки build_eclipse.bat
cls
echo off
set project_name=Some_Project
set project_dir=%cd%
echo project_dir=%project_dir%
set ide_tool=eclipsec.exe
set workspace_dir=%project_dir%\..\..\..\
echo workspace_dir=%workspace_dir%
call %ide_tool% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data %workspace_dir% -build %project_name%/Debug -cleanBuild %project_name%/Debug | tee build_log.txt
При этом Eclipse откажется собирать проект, если вы предварительно не сделаете refresh вручную мышкой из-под IDE. Понимаете всю глубину наших глубин? Как сделать авто refresh из командной - тоже строки не ясно. Нигде про это не написано. Это ещё один гвоздь в крышку гроба Eclipse ARM плагинов. Это проблема № 4.
Проблема №5: Проблема с генерацией артефактов
К сожалению, Eclipse c ARM плагинами не может одновременно сгенерировать *.hex и *.bin артефакты. Либо *.hex либо *.bin. Поэтому пришлось прописать синтез *.bin отдельно в скрипте перепрошивки утилитой arm-none-eabi-objcopy
Вот скрипт файла flash_bin.bat
echo off
cls
set project_name=RTOS_BoardName_Project
set project_dir=%cd%
echo project_dir=%project_dir%
set artefact_elf=%project_dir%\Debug\%project_name%.elf
set artefact_bin=%project_dir%\Debug\%project_name%.bin
echo artefact_bin=%artefact_bin%
arm-none-eabi-objcopy -O binary -S %artefact_elf% %artefact_bin%
::set flash_tool=ATLink_Console.exe
set flash_tool=ATLink_Console.exe
set options=-device AT32F437ZMT7 -connect -p --dfap --depp -d --a 08000000 --fn %artefact_bin% --v -r
%flash_tool% %options%
pause
Вот лог успешной перепрошивки
Либо, как вариант, можно добавить настройку генерировать бинарный *.bin файл как Post-build-steps. Находится это поле по следующему GUI-IDE адресу в GUI: Рroperties → C/C++ Build → Settings → Build Steps → Post‑build‑steps
arm-none-eabi-objcopy.exe -O binary -S RTOS_BoardName_Project.elf RTOS_BoardName_Project.bin
Причем если взять один и тот же проект и на разных компах, добавить этот Post-build-steps, то .cproject будет, внимание, на 30% разный! Хотя оба User(a) IDE мышкой выполнили одни и те же действия. Вот так, господа.... Вы уже любите Eclipse ARM плагины?
Пошаговая отладка
В принципе, пошаговой отладке абсолютно всё равно какая IDE. Пошаговой отладке нужен только GDB сервер, GDB клиент и специально подготовленный *.elf файл. Далее можно хоть из консоли код по строчкам проходить.
Пошаговая GDB отладка ARM процессора из консоли в Win10 https://habr.com/ru/articles/694708/
Минусы сборки Eclipse плагинами из-под IDE
Конфиги внутри .cproject не отсортированы. Хотя IDE могла бы это и сделать. В результате у двух похожих проектов diff .cproject 99,99%.
-
Высокие накладные расходы на создание ещё одной сборки. Как следствие создавать отдельные сборки для конкретных плат User(ам) IDE лень. В итоге у всех одна сборка - Франкенштейн сразу для всех электронных плат.
Eclipse плагины не позволяют менять код во время компиляции. Программа может собираться долго. И ваша работа парализована на время сборки.
Eclipse плагины собирают всё что лежит в папке. Как то что нужно, так и то, что не нужно. Это провоцируют путаницу и ошибки.
Много мышковозни. Вы конечно можете открыть файл настроек проекта .cproject и дополнять его в текстовом редакторе. Однако эти действия не легальны как бы... При этом если Вы случайно измените там в ненужном месте лишний символ, то у вас перестанет собираться сборка. Весь проект на помойку! Вас же при этом от страха застигнут судороги, конвульсии и паралич. Оно вам надо? Может всё-таки на 7м году опыта уже лучше самим писать скрипты сборки? A?...
Достоинства сборки из-под Eclipse c ARM плагинами
++Если Вы ещё пока слабо разбираетесь в языке сборки make, то Вы можете проанализировать те makefile(ы), которые для Вас любезнейшим образом синтезировали Eclipse ARM plugins и, на основе этого, написать свои более структурированные и модульные makefile(лы). Вот, пожалуй, хорошее достоинство ARM plugins для Eclipse.
++Eclipse IDE c плагинами это средство избавления от санкционных и дорогих IDE IAR и Keil.
++Eclipse IDE c плагинами это бесплатный инструментарий для сборки прошивок.
Вывод
У меня был случай, когда была одна Legacy IDE сборка 55-ю конфигурациями и надо было для всех конфигураций написать ещё пару .c файлов. Дак вот. Код я написал за 3-4 часа. Однако у меня ушла целая неделя тупо на то чтобы просто в каждую конфигурацию добавить папку, прописать пути к этой папке и добавить макросы в GUI IDE. Вот так, господа...
Поэтому я крайне не рекомендую собирать проекты ARM плагинами Eclipse! Это, к слову, также касается и IDE IAR и IDE Keil. Лучше пишите сами make скрипты сборки. Вот методичка.
Плюсов в сборке из-под IDE я не нахожу. Одни только проблемы. Темпы разработки очень низкие. Новые сборки создавать трудно, предстоит полное дублирование конфигов, поддерживать прежние сборки тоже проблематично. Файл настройки .cproject у всех разный, даже если конфиги логический одинаковые.
Eclipse c плагинами крайне непригоден для сборки из-под командной строки. Eclipse c плагинами - это только соло разработка. Только ручные сборки.
Что же делать?
Пишите сами скрипты сборки. Вариантов масса: Make, Ninja, Cmake. Если и возникнут ошибки сборки, то в логе хотя бы будет понятный комментарий об ошибке. Так же Вы сможете вообще использовать любой текстовый редактор.
Links
Комментарии (13)
yappari
22.03.2024 13:43Eclipse плагины собирают всё что лежит в папке. Как то что нужно так и то что не нужно. Это провоцируют путаницу и ошибки.
Странный пункт. Что там может быть "не нужно"? Если оно действительно не нужно, зачем оно там? Если не участвует в сборке, то парой-тройкой кликов добавляется в исключения.
aabzel Автор
22.03.2024 13:43Что там может быть "не нужно"? Если оно действительно не нужно, зачем оно там?
Там может быть код для MCU с бОльшими ресурсами по памяти, который в данной сборке не нужен.
vdshat
22.03.2024 13:43Все проблемы сборки возникают от непонимания задач разработчика. Основная задача разработчика - автоматизировать рутинные операции для большей производительности. Если разработчик даже свою работу не в состоянии автоматизировать и упростить, начиная с изучения горячих клавиш, то ... ой!
Одна из следующих по критичности задача - обеспечение повторяемости результата. Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант. А плагины IDE могут вносить свои коллизии из-за разных версий и своей идеологии.
Используйте системы сборки как с общими настройками, так и частными под проект. Инструменты же тут могут быть разнообразные. Как говориться: "На вкус и цвет". Но даже с системами сборки не забывайте про макросы, шаблоны, bash/bat-скрипты и симлинки (в Windows они тоже есть), т.к. автоматизировать и оптимизировать можно, практически, до бесконечности.
aabzel Автор
22.03.2024 13:43Основная задача разработчика - автоматизировать рутинные операции для большей производительности.
Это скорее задача DevOps(а). Задача разработчика сделать продукт.
aabzel Автор
22.03.2024 13:43Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант
Очень даже вариант, если Вы определяете переменные окружения в make скриптах. Вот пояснение https://habr.com/ru/articles/798213/
В make нет таких строгих ограничений на длину переменной окружения как в CMD .
MikeSmith
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение.
Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32.
Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
aabzel Автор
MikeSmith
Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь:
Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
aabzel Автор
Согласен в Вами. Одно достоинство Eclipse ARM plugins всё таки есть.
Если Вы ещё пока слабо разбираетесь в языке сборки make, то Вы можете внимательно проанализировать те makefile(ы), которые для Вас любезнейшим образом синтезировали Eclipse ARM plugins и, на основе этого, раздербанить их и написать свои более структурированные и модульные makefile(ы). Вот, пожалуй, единственное достоинство ARM plugins для Eclipse.
MikeSmith
Ещё добавлю с копилку достоинств - как средство избавления от ХалоКубо/Кейло/Иаро-зависимости. Перейти на GCC и чистый мейк (при реальной необходимости) с embed-cdt плагина гораздо проще, чем с Иара.
aabzel Автор
diff одинаковых сборок достигает 99%
aabzel Автор
make файл пишется один раз и слабо меняется со временем.
Причем make файл можно сгенерить из STMCubeMX.
aabzel Автор
Проблема, если у Вас сборки собирает Jenkins ( почитайте про CI / CD)