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

Пролог

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

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

Cпециалисты без профильного образования построили самолёт

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

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

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

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

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

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

Всё это сваливается в файл .cproject. Этот файл .cproject — это авто‑генеренный файл, в который руками лучше не соваться. Ибо если Вы случайно там что‑то поменяете и сохраните, то в один утренний день у Вас просто не откроется проект! Далее у Вас начнется приступ судороги, конвульсии и паралич. Нормально так, да?... Это проблема номер 1.

Проекты разработанные в IDE с плагинами порой очень нелепо скомпонованы...

Проблема №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: Ручное прописывание макро определений для препроцессора

В наше-то время прописывать макросы в глубинных настройках GUI-IDE это как летать на бипланах

Вторая беда 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_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 из-под командной строки - тоже не ясно. Нигде про это не написано. Люди на форумах жалуются, что нереально сделать авто refresh из-под командной строки. Это, к слову, 4тый гвоздь в крышку гроба Eclipse ARM плагинов. Вы уже понимаете всю глубину наших глубин?

Запуск сборки только мышкой из-под GUI-IDE - это так же нелепо как летающие танки.

Проблема № 5, Ручное прописывание ключей компоновщику

При сборке через плагины, вам надо также вручную мышкой прописывать ключи для компоновщика . Например -lm для подключения математических функций (sin, log, cos).

Проблеме в том, что это надо проделывать для каждой отдельной сборки, даже если код у сборок общий. То есть опять происходит бессмысленное дублирование конфигов и лишняя работа.

Дублирование конфигов это как самолёт с двумя штурвалами.

Проблема №6: Проблема с генерацией артефактов

К сожалению, Eclipse c ARM плагинами не может одновременно сгенерировать *.hex и *.bin артефакты. Либо *.hex либо *.bin. GUI прошивальщики требуют 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) GUI-IDE мышкой выполнили одни и те же действия. Вот так, господа.... Вы уже любите Eclipse ARM плагины?

Проблема в том, что user(ы), которые используют сборку из-под IDE, считают своё решение гениальным!

Пошаговая отладка

В принципе, пошаговой отладке абсолютно всё равно какая 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 плагинами.

   Издевка судьбы ещё и в том, что одной сборки обычно никогда не бывает! Для каждой электронной платы нужно как минимум пять сборок! Следите за руками... Первичный загрузчик (MBR), Вторичный загрузчик, Generic release, assembly test, Generic debug. Плюс сборки для того чтобы гонять прошивку на отладочных платах от производителя микроконтроллера, пока ваше изделие находится в производстве. Уже получается минимум 6 сборок, господа. Вот и получается, что надо сразу начинать разработку на основе самостоятельно написанных make скриптов, а не на этих ваших пресловутых Arduino(обрахных) GUI(невых) IDE. Вот такие вот пирожки с капустой, понимаете...

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

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

5. Много мышковозни. Вы конечно можете открыть файл настроек проекта .cproject и дополнять его в текстовом редакторе. Однако эти действия не легальны как бы... При этом если Вы случайно измените там в ненужном месте лишний символ или оставите пробел или TAB, то у вас перестанет собираться сборка! Весь проект на помойку! Вас же при этом от страха застигнут судороги, конвульсии и паралич. Оно вам надо? Может всё-таки на 7м году опыта уже лучше самим писать скрипты сборки? A?...

Достоинства сборки из-под Eclipse c ARM плагинами

++Если Вы ещё пока слабо разбираетесь в языке сборки make, то Вы можете проанализировать те makefile(ы), которые для Вас любезнейшим образом синтезировали Eclipse ARM plugins и, на основе этого, написать свои более структурированные и модульные makefile(лы). Вот, пожалуй, хорошее достоинство ARM plugins для Eclipse.

++Eclipse IDE c плагинами это средство избавления от санкционных и дорогих IDE IAR и Keil.

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

++Многие пользуются Eclipse IDE только потому, что им нужна функция автоматического форматирования отступов в исходниках горячей кнопкой Ctrl+Shift+F. А утилитой clang-format.exe или GNU indent они пользоваться не умеют.

++В Eclipse плагинах есть функция - дымовая завеса кода

++Плюс разработки в IDE в том, что можно годами, как пиявка, высасывать из организации зарплату за то, что через те же Make скрипты-сборки можно сделать максимум за 3-4 месяца. Именно по этой причине embedded стартапы и не используют IDE, а используют, как раз, именно самописные скрипты сборки (Make, CMake, Ninjia, Meson и прочее).

------------------------------

Если проводить аналогии с атомной энергетикой то, сборка через GUI-IDE - это как реакторы на горизонтальных ТВЭЛах (сборках), а сборка из скриптов это реактор на вертикальных ТВЭЛах.

Горизонтальные реакторы неудобны, так как надо минимум две точки подвеса ТВЭЛа при загрузке топлива. Плюс нужны дополнительные усилия, чтобы проталкивать стержни в активную зону. Потом стержень может расплавиться и застрять. Тогда жди беды.

Напротив, вертикальные ТВЭЛы загружаются под действие силы тяжести и для транспортировке сборки нужна только одна точка подвеса. Расплавленные ТВЭЛы просто стекают в поддон. Easy!

War story

В одной западной компании мы делали прошивки для заурядных плат, которые, по сути, перекладывают байты. Там были самописные Make скрипты сборки. Каждому программисту удавалось для новой платы написать прошивку за 2-3 недели. До этого я делал, то же самое в другой российском компании, но только в IAR и Keil. И в целом, на разработку прошивки для одной точно такой же электронной платы уходило 2-3 года! Делайте выводы, господа...

Поэтому GUI-IDE - это идеальный инструмент для масштабирования разработки во времени. Пока идет разработка прошивки в Eclipse-IDE с плагинами, там, глядишь, и 35-летняя ипотека выплатится. Успех!

в IDE можно масштабировать разработку во времени, как этот вертолет масштабировался в пространстве

Вывод

У меня был случай, когда была одна Legacy IAR-IDE сборка 55-ю конфигурациями и надо было для всех конфигураций написать ещё пару *.c файлов. Дак вот... Код я написал за 3-4 часа. Однако у меня ушло две недели тупо на то, чтобы просто в каждую конфигурацию мышкой добавить папку, прописать пути к этой папке и добавить макросы в GUI IDE. Вот так, господа...

Проблема IDE плагинов в том, что Вы отдаете управление над ситуацией каким-то левым плагинам, написанными непонятно кем. У вас происходит control leak. Это тоже что у летчика самолет перестанет слушаться штурвала.

Это то же что, если бы другой посторонний человек диктовал бы вам каждый день как вам надо одеваться. И предлагал мятую одежду, рваные носки и рубашку без некоторых пуговиц на рукавах. В дождь выходить без зонта и прочее. Оно вам надо? Вероятно вы сами хотите выбирать себе повседневную одежду? Так?

Потом, собирать прошивки в Eclipse с плагинами IDE c плагинами это также неэффективно как ездить на квадратных колёсах.

Проекты собранные в IDE с плагинами поражают своей нелепой компоновкой

Поэтому я крайне не рекомендую Вам собирать проекты ARM плагинами Eclipse! Это, к слову, также касается и IDE IAR и IDE Keil. В 2024 году программировать в IDE c плагинами - это тоже, что лаптями щи хлебать. GUI-IDE - это для тех кто не в теме. Собирать прошивки в GUI IDE это как строить деревянные самолёты вместо металлических.

Лучше пишите сами Make/CMake скрипты сборки. Вот методичка. Это даже проще. Ваша жизнь заиграет новыми красками... Вы сможете масштабироваться хоть до Луны.

Обоснованных плюсов в сборке из-под IDE я вообще не нахожу. Одни только проблемы. Темпы разработки очень-очень низкие. Новые сборки создавать трудно, предстоит полное дублирование конфигов, поддерживать прежние сборки тоже тяжко. Файлы настройки .cproject у всех разные как снежинки, даже если конфиги логически одинаковые.

Также Eclipse c плагинами крайне неприспособлен для сборки из-под командной строки. Это сразу перечеркивает автосборки в Jenkins(е) и вообще DevOps как таковой. И вы автоматически оказываетесь где-то в 198x...199x годах.

Eclipse c плагинами - это только кактус-соло разработка. Только ручные сборки. Ремесленничество, не фабрика. Понимаете?...

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

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

Ездите на круглых колесах. Пишите скрипты сборки сами!

Links

• Развертывание среды разработки для STM32: раз и два

• Почему важно собирать код из скриптов

• ToolChain: Настройка сборки прошивок для микроконтроллеров Artery из Makefile

• Дымовая Завеса в Eclipse IDE

• How to link Eclipse Project with -lm library for "floor" and "pow" function?