Tuning toolchain for Arduino for continuing

Once upon a time, it happened to me to work on a project with Arduino , where there were quite specific requirements for the predictability of code generation, and working with a black box in some places was annoying. So the idea was born to slightly adjust the assembly process and introduce some additional steps during the assembly.

As you know, the Wiring language is actually a full-fledged C ++, from which support for exceptions is removed due to their heaviness for the runtime environment and some subtleties associated with the program structure are hidden, such as the implementation of the main function, and the developer is given the setup and loop functions that are called from main

And this means that you can use the C ++ buns, even if no one talked about them.

Everything described in the article applies to versions of the Arduino environment from at least 1.6. I did everything under Windows, but for Linux / MacOS the approaches remain the same, the technical details just change.

So, let's get started.

In version 1.6 environment, the GCC version 4.8 compiler is used by default, in which C ++ 11 support is not enabled by default, but we want auto, varadic templates and other goodies, isn't it? And in the environment of version 1.8, the compiler is already version 4.9, which supports C ++ 11 by default, but it can also be forced to use C ++ 14 with its rvalue reference, constant expressions, separators, binary literals, and other joys.

To add support for newer standards than are included by default, open the file in the Arduino installation directoryhardware\arduino\avr\platform.txtcontaining the compilation settings, find the parameter there compiler.cpp.flagsand indicate the desired language standard: -std=gnu++11replace with -std=gnu++14. If there is no parameter, add, for example, at the end of the line.

After saving the file, you can try rebuilding the sketch - the environment will pick up the new settings immediately.

Here you can change optimization settings, for example, instead of a more compact code, by changing the option -Osto -Ofastenable the generation of faster code.

These settings are global, therefore applicable to all projects.

Then I decided to get more detailed control over the result of the compiler and added some analogue of postbuild events. To do this, add the parameter to the same filerecipe.hooks.postbuild.0.patternwhose value should contain the name of the file that will be launched after the assembly, and command line arguments. I assigned it a meaning "{compiler.path}stat.bat" "{build.path}/{build.project_name}". Since there is no such file yet, it must be created in the directory hardware\tools\avr\bin(with the name, obviously stat.bat).

Let's write the following lines there:

"%~dp0\avr-objdump.exe" -d -C %1.elf > %1.SX
"%~dp0\avr-nm.exe" %1.elf -nCS > %1.names

The first line starts the decompilation of the already compiled and optimized program using objdump, creating an output file with the project name and the additional extension .SX (the choice is arbitrary, but we assume that S is traditionally assembler, and X indicates the fact of some conversion).

The second line extracts the symbolic names of the memory areas by running the nm command and generates reports in the file with the additional extension .names, while sorting is performed by addresses.

Here it is also necessary to add that the assembly is carried out in a temporary directory, and to see it, you need to go into the Arduino settings and enable the “Show detailed output” -> “Compilation” checkbox, then run this very compilation and see where the assembly is going. In my case (IDE version 1.8.5) it was a view directory %TEMP%\arduino_build_[random].

Reading disassembled code in ordinary life is a dubious pleasure, but it might be necessary for someone (I have happened).

The file of names as a whole is more useful. In the spoiler - a test sketch with which experiments were performed:


The resulting file of names entirely also under the spoiler:



How to read it? Let's get it right.

AVR controllers have two independent memory areas: program memory and data memory. Accordingly, a pointer to a code and a pointer to data are not the same thing. I am silent about EEPROM, there is a separate conversation about addressing. In the dump, the program memory is located at offset 0 and execution starts from it, and there is also a table of interrupt vectors, 4 bytes per element. Unlike x86, each interrupt vector does not contain the address of the handler, but an instruction that must be executed. Usually (I have not seen other options) - jmp, that is, the transition to the desired address. We will return to interrupt vectors only for a short while, but for now we look further.

Data memory consists of two parts: a register file at offset 0 and data in random access memory (SRAM) at offset 0x100. When a memory dump is output, the offset 0x00800000 is added to the SRAM addresses, which does not mean anything in essence, but is just convenient. I also note that the EEPROM offset has a value of 0x00810000, but we do not need this.

Let's start with the data, everything is a bit simpler and more familiar here, and then back to the code. The first column is the offset, the second is the size, then the type (until we pay attention), then to the end of the line is the name.

We go to offset 0x00800100 and see the entries there:

00800100 D __data_start
00800100 00000002 D counter
00800102 00000010 V vtable for HardwareSerial
0080011c D __data_end

It is an analogue of the .data section and contains initialized global and static variables, as well as virtual method tables. These variables will be initialized with bootstrap code, which will take some time.

We go further (let it not bother you that __bss_start and __data_end go in random order - they have a common address).

0080011c B __bss_start
0080011c 00000004 b test(int)::time
00800120 00000001 b timer0_fract
00800121 00000004 B timer0_millis
00800125 00000004 B timer0_overflow_count
00800129 0000009d B Serial
008001c6 B __bss_end

This is a section of uninitialized data (similar to .bss). It is given for nothing, since it is filled with zero bytes. Here are a few helper variables, names that start with timer0_, a global Serial object, and our static local variable.

A small lyrical digression: note that the Serial object is initially empty, and it will be initialized when the begin method is called on it. There are several reasons for this. Firstly, it may not be used at all (then it will not be created at all and no place will be allocated for it), and secondly, we know that the order of initialization of global objects is not defined, and strictly speaking, the controller not initialized correctly.

At higher addresses, the stack is located. If the controller has 2 kilobytes of memory (boards based on the atmega328 processor), then the last address will be 0x008008FF. From this address the stack begins and it grows in the direction of decreasing addresses. There are no barriers, and in principle, the stack can crawl onto variables, ruining them. Or the data can ruin the stack - how lucky. In this case, nothing good will happen. This can be called undefined behavior, but it is better to always leave enough space for the stack in memory. How much is hard to say. That was enough for local variables and stack frames of all calls plus for the heaviest interrupt handler with all nested calls. I honestly did not find a more or less honest decision on how to diagnose the use of the stack.

Let's get back to the code. When I said that the code was stored there, I was a little disingenuous. In fact, read-only data can be stored there, but they are extracted from there by special instructions from the LPM processor. So, constant data can be placed there and placed for nothing, because time is not wasted on their initialization. Note the macros F (...) in the code. They just declare the lines placed in the program memory and then does a little magic. We will not go into the details of magic, but look for them in memory. Such macros go to the test function, and in the dump we will see them as

00000068 0000001a t test(int)::__c
00000082 0000000b t test(int)::__c
0000008d 00000005 t test(int)::__c
00000092 0000000a t test(int)::__c

Despite the fact that they have the same name, they are located at different addresses. Because the macro F (...) creates a scope in curly brackets, and variables (more precisely constants) do not interfere with each other. If you look at the disassembled dump, then these will be the addresses of the lines in the program memory.

And finally, the promise of interruptions. Libraries use some controller resources to support peripherals: timers, communication interfaces, etc. They register their interrupt handlers, store their variables in memory, and constants in program memory. If you compile an empty sketch, then the memory dump will be like this:


A lot, isn't it?

And here is the code:


A timer interrupt is involved, 9 bytes to service this timer, and a certain amount of infrastructure code.

For today, perhaps enough. I hope this is useful to someone.