Eclipse Building Using ARM GCC Plugins

Prologue

In programming microcontrollers, Eclipse with plugins is often used because it contains plugins that generate make files for building C programs according to the project markup in XML called .cproject And .project.

These plugins were made mainly to involve schoolchildren and other specialists without specialized IT education and experience in the process of programming microcontrollers.

Next I will write why building with Eclipse plugins for the IDE is not suitable for industrial programming.

The theory of building C programs in an IDE with plugins

Essentially, building any C code in an IDE comes down to three simple but very common steps:

–1 Add with the mouse source code for the project

–2 Add with the mouse paths to code folders

–3 add with the mouse preprocessor macros for the project

All this is dumped into a file .cproject. This .cproject is an auto-generated file that it is better not to mess with your hands. If you accidentally change something there and save it, then one morning your project simply won’t open! Next, you will begin to experience seizures, convulsions and paralysis. Is that normal right?..

Problem #1: Manually Writing Paths

This is the most painful issue when building with an IDE with plugins.

When building from an IDE, you will always have to manually specify paths to software components and header files in the IDE settings using the mouse

"${workspace_loc:/${ProjName}/control/system}"
"${workspace_loc:/${ProjName}/control}"

But there is one trick. It consists of setting the paths to the environment variable INCDIR and feed it to the IDE. You can write a *.bat script.

@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

This script must be run before launching Eclipse. It is very important here that the dash is exactly like this “/”. Otherwise, the build system will not recognize this path. Next you need to write a make variable ${INCDIR} right here

However, everything is not so smooth here either. The maximum length of an environment variable in cmd is only 8192 characters. And you can save setx between sessions and only 1024 characters in one environment variable. So it turns out that only very few paths can be written this way.

Problem #2: Manually writing macro definitions for the preprocessor

The second problem is manually writing preprocessor macros. Macros are registered here Properties->C/C++ Builds-> Settings->Tool Settings -> GNU Arm Cross C Compiler -> Preprocsssor-> Define Symbol (-D)

here in the GUI window you add and register your macros one by one with the mouse. Then click Apply and Close

Advanced way to pass macro definitions

However, you can transfer the file extra_config.h with macros option -include by adding the line -include extra_config.h in the compiler settings.

As you can see in the build log, macros are passed successfully from outside

Building the project
The assembly can be initiated with the mouse or the hotkey Ctrl+B, or also with the mouse from the IDE.

Re-Firmware

If you do not have administrator rights on your PC to change the PATH variable, you can change the PATH variable each time from the Windows cmd console like this

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

After this, you can safely run the build script 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

In this case, Eclipse will refuse to build the project if you do not refresh manually from within the IDE. How to do auto refresh from the command line is not clear. This is another nail in the coffin of Eclipse ARM plugins.

Problem #3: Problem with artifact generation

Unfortunately, Eclipse with ARM plugins cannot generate *.hex and *.bin artifacts at the same time. Either *.hex or *.bin. Therefore, I had to register the *.bin synthesis separately in the flashing script using the utility arm-none-eabi-objcopy

Here is the file script 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

Here is the log of successful flashing

Or, as an option, you can add the option to generate a binary file as Post-build-steps. This field is located at the following GUI-IDE address in the GUI: Properties -> 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

Moreover, if you take the same project and add this Post-build-steps on different computers, then the .cproject will be 30% different! Although both User(a) IDEs performed the same actions with the mouse. Like this…

Step by step debugging

In principle, step-by-step debugging doesn’t matter what IDE it is. Step-by-step debugging only requires a specially prepared GDB server, a GDB client and an *.elf file. Then you can even go through the code line by line from the console.

Disadvantages of building Eclipse with plugins from within the IDE

1-configs inside cproject are not sorted. Although the IDE could do this. Two similar projects have a huge diff.cproject.

2–High overhead for creating another assembly. It is too lazy to create separate assemblies for specific boards of the User(s) IDE. As a result, everyone has one assembly – Frankenstein for all boards at once.

3—Eclipse plugins do not allow you to change code during compilation. The program can take a long time to assemble. And your work is paralyzed during assembly.

4—Eclipse plugins collect everything that is in the folder. Both what is needed and what is not needed. This causes confusion and errors.

5—A lot of mouse fiddling. You can of course open the .cproject project settings file and add to it in a text editor. However, these actions are not legal, as it were. Moreover, if you accidentally change an extra symbol there in an unnecessary place, then your assembly will no longer be assembled. The whole project is in the trash. At the same time, you will be overtaken by cramps, convulsions and paralysis from fear. Do you need it? Maybe it’s still better to write assembly scripts yourself?
It will take you one day to simply register macros in the GUI IDE

Advantages of building from Eclipse with plugins

None.

Conclusion
I highly recommend not building ARM projects using Eclipse plugins. It's better to write your own make build scripts. Here is the manual https://habr.com/ru/articles/792590/.

I don’t find any advantages in assembling from the IDE. Only problems. The pace of development is very slow. It is difficult to create new assemblies; you have to completely duplicate configs; maintaining previous assemblies is also problematic. Settings file .cproject Everyone has a different one, even if the logical configs are the same.

Eclipse with plugins is extremely unsuitable for building from the command line. Eclipse with plugins is only for solo development. Only manual assemblies.

What to do?
Write your own build scripts. There are a lot of options: Make, Ninja, Cmake.

Links

Deploying a development environment for STM32 https://bravikov.wordpress.com/tag/gnu-arm-eclipse/
https://mcuoneclipse.com/2014/09/12/building-projects-with-eclipse-from-the-command-line/

ToolChain: Setting up firmware assembly for Artery microcontrollers from Makefile https://habr.com/ru/articles/792590/