Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь

от автора

Пролог

В программировании микроконтроллеров часто Eclipse с плагинами используют потому что в нем есть плагины, которые генерируют make файлы для сборки программ на Си, согласно разметке проекта в XML под названием .cproject и .project.

Эти плагины были сделаны, главным образом, для того, чтобы вовлечь в процесс программирования микроконтроллеров школьников и прочих специалистов без профильного IT образования и опыта в области Computer Science. Понимаете?

Далее я напишу почему сборка с Eclipse плагинами для IDE не годится для промышленного программирования.

Теория сборки Си программ в IDE c плагинами

По сути, построение любого Cи-кода в IDE сводится к трем простым, но очень частым действиям

  1. Добавить мышкой исходник к проекту

  2. Добавить мышкой пути к папкам с кодом

  3. Добавить мышкой макросы препроцессора к проекту

Всё это сваливается в файл .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

  1. Конфиги внутри .cproject не отсортированы. Хотя IDE могла бы это и сделать. В результате у двух похожих проектов diff .cproject 99,99%.

  2. Высокие накладные расходы на создание ещё одной сборки. Как следствие создавать отдельные сборки для конкретных плат User(ам) IDE лень. В итоге у всех одна сборка — Франкенштейн сразу для всех электронных плат.

    Проект собранный в Eclipse c ARM плагинами.

    Проект собранный в Eclipse c ARM плагинами.
  3. Eclipse плагины не позволяют менять код во время компиляции. Программа может собираться долго. И ваша работа парализована на время сборки.

  4. Eclipse плагины собирают всё что лежит в папке. Как то что нужно, так и то, что не нужно. Это провоцируют путаницу и ошибки.

  5. Много мышковозни. Вы конечно можете открыть файл настроек проекта .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 плагинами — это только соло разработка. Только ручные сборки.

Eclipse c плагинами также удобен как вот эта ручка на Почте России.

Eclipse c плагинами также удобен как вот эта ручка на Почте России.

Что же делать?
Пишите сами скрипты сборки. Вариантов масса: Make, Ninja, Cmake. Если и возникнут ошибки сборки, то в логе хотя бы будет понятный комментарий об ошибке. Так же Вы сможете вообще использовать любой текстовый редактор.

Links

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете код из скриптов?

50% да20
50% нет20

Проголосовали 40 пользователей. Воздержавшихся нет.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете код из-под IDE?

79.49% да31
20.51% нет8

Проголосовали 39 пользователей. Воздержавшихся нет.

ссылка на оригинал статьи https://habr.com/ru/articles/794206/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *