Arduino build process?

Using Arduino Programming Questions
1

Hi Guys,

I'm trying to find out which core files the IDE chooses to build when compiling a sketch, but I can't find any documentation on this

I've read the docs on the build process Arduino IDE 1.5 3rd party Hardware specification · arduino/Arduino Wiki · GitHub but I can't see any mention of how the IDE determines precisely which cpp , c and s files to compile.

It just looks like it compiles them all, this this correct

BTW. The reason I need to know this is because I'm working on a port to alternative hardware using (STM32F4 Discovery), using code written for the STM32F1 series

Thanks

Roger

2

It just looks like it compiles them all, this this correct

Enable verbose mode when compiling, and see for yourself.

3

Or just look in the code for the IDE (it's open source) and I assume its the IDE code your porting.

Mark

4

Guys,

I have verbose enabled and I can see what its compiling, but what I'd love to know is where the build rules that determine which cpp, c and s files are compiled.

What I'm trying to do is to support several different microcontrollers using the new feature in 1.5 where the My Documents Arduino folder can have a hardware folder inside it.
(There is a massive thread about it in the microcontrollers section.)

However although the code I have works for the STM32F1 series of processors, I now have a STM32F407 processor board I want to use.

But I don't want to completely duplicate all the code for the F1 into a whole new section of hardware, I

I've looked in boards.txt and platforms.txt but I can't see that platforms.txt (or boards.txt) specifices which source files to compile.

e.g the recipies in platform.txt

## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mcpu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.c.extra_flags} {build.extra_flags} {compiler.libsam.c.flags} {includes} "{source_file}" -o "{object_file}"

Just appears to be describing how to compile a c (or cpp or s file), rather than defining search paths to look for the source files.

e.g. How does the IDE know to look in the cores, and system folders etc

I can see that in some places there are .mk files, that may be part of the process, but I can only see one of these files in 1.5.8 in the SAM tree for Due.

So it looks like the IDE just searches through, For Example. the hardware/arduino/avr folder and then possibly compiles every c, cpp or s file it encounters ?

I'm not sure what the variant folder does e.g. in SAM

There seems to be a make file in in build_gcc

Is the build process for this documented anywhere ?

5

So it looks like the IDE just searches through, For Example. the hardware/arduino/avr folder and then possibly compiles every c, cpp or s file it encounters ?

Yes, approximately.
It builds up a list of directories that need to be compiled:

  1. The user's sketch directory.
  2. any library directory, parsed from the #include statements in the user's sketch.
  3. The 'core', derived from the the location of boards.txt, the board that is configured, and the "core" and "variant" variables defined within the board definition.
    Then it compiles all the files in those directories, with possible pre-processing for .ino files.

I think it's all in Arduino/app/src/processing/app/debug/Compiler.java at 1.5.8 · arduino/Arduino · GitHub

Be careful not to be confused the "processing" code that's still present in the tree (Sketch.Java?)

6

@westfw

Thanks

Edit.

can you tell me what the system folder does ?

It seems to be refernced in the include paths of SAM, but I none of the source files eg. adc.c seem to be compiled by the IDE

Is there a separate library build process ? e.g. to make a ".a" or ".lib" file that is used as part of the IDE link process ??

Edit 2.

Could you tell me what the purpose of this is

gcc-arm-none-eabi-4.8.3-2014q1/bin/arm-none-eabi-ar rcs core.a dtostrf.c.o

etc

It appears to combine all the .o files into core.a

Though as it seems to do this each and every time the code builds, I'm not sure why it bothers to do this ???

7

Maybe out of date, but for reference ...

rogerClark:
can you tell me what the system folder does ?

It seems to be refernced in the include paths of SAM, but I none of the source files eg. adc.c seem to be compiled by the IDE

Is there a separate library build process ? e.g. to make a ".a" or ".lib" file that is used as part of the IDE link process ??

The system folder is an extra for Due, it is not part of the auto-compiled source. The Due implementation is built on top of Atmel ASF, so system effectively contains that. The system folder could probably be compiled under cores, although it is slow to compile all those files.

There is a separate command line build process to build libsam_sam3x8e_gcc_rel.a which must be then copied to variants folder. This is done when you build the Arduino IDE, I think, or it might even be a manual step.

The system/libsam_sam3x8e_gcc_rel.a is quite messy, or at least it is not fully thought through.

I had a lot of problems with weak symbols in libraries and possibly other issues which affect the build so I would prefer building and linking .o files directly. The IDE should avoid rebuilding .o anyway, so building libraries seems a bit of an unnecessary step.

Could you tell me what the purpose of this is

gcc-arm-none-eabi-4.8.3-2014q1/bin/arm-none-eabi-ar rcs core.a dtostrf.c.o

etc

It appears to combine all the .o files into core.a

Though as it seems to do this each and every time the code builds, I'm not sure why it bothers to do this ???

I'm fairly sure that core.a only needs to be built once and it is a bug that it is rebuilt each time. Possibly there is LGPL license issue, I'm not quite sure.

8

Building the core into a single .a file for the core libraries is sort-of standard practice, although I guess the use of -ffunction-sections and -gc-sections renders it somewhat obsolete. It does still allow the decisions about what is in the core to be separate from the sketch: "compile the core", "compile the libraries", "compile the sketch", "link them all together.

There's no good reason to do it every compile. Originally, the core was small and the compile process always compiled everything. The use of already compiled objects is recent, but the build process really isn't smart enough to duplicate all the logic of Make. (Nor should it be, IMO. It should start using Make (or one of the other build tools) instead.)

Using pre-compiled-once core libraries for STM32 is an idea; I don't think that they have as much chip-to-chip variation as the AVRs.