Tuning toolchain for Arduino for continuing

A long time ago it happened to me to work on a project with Arduino , where there were quite specific requirements for the predictability of code generation, and it was annoying to work with a black box in places. So the idea was born to somewhat tune the assembly process and introduce some additional steps in the assembly.



As it is known, the Wiring language is actually a full-fledged C ++, from which the exclusion support has been removed due to its heavy weight for the runtime environment and some subtleties related to 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 main.



And this means that you can use C ++ buns, even if nobody told about them.



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

')

So, we proceed.



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



To add support for newer standards than those included by default, you need to open the hardware\arduino\avr\platform.txt file containing the compilation settings in the Arduino installation directory, find the compiler.cpp.flags parameter and specify the desired language standard: -std=gnu++11 replace 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 to re-compile the sketch - Wednesday will pick up the new settings immediately.



Here you can also change the optimization settings, for example, instead of a more compact code, by changing the -Os option to -Ofast enable the generation of faster code.



These settings are global, therefore applicable in 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 recipe.hooks.postbuild.0.pattern to the same file, the value of which should contain the name of the file that will be launched after the assembly, and command line arguments. I assigned it the value "{compiler.path}stat.bat" "{build.path}/{build.project_name}" . Since there is no such file yet, it must be created in the hardware\tools\avr\bin (with the name, obviously, stat.bat ).



We write there the following lines:

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

The first line starts decompiling an already assembled 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 an 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 a report in the file with the additional extension .names, while sorting is performed by addresses.



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



To read a disassembled code in ordinary life is a dubious pleasure, but maybe someone will need it (I used to).



The name file is generally more useful. In the spoiler - a test sketch with which the experiments were performed:





The resulting name file is also under the spoiler:







How to read this? Let's figure it out.



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



The data memory consists of two parts: a register file at offset 0 and in-memory data (SRAM) at offset 0x100. When a memory dump is displayed, an offset of 0x00800000 is added to the SRAM addresses, which means nothing in essence, but simply convenient. I also note that the EEPROM offset is 0x00810000, but we do not need it.



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



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

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

This 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 by bootstrap code, which will take some time.



Then we go (let you not be embarrassed that __bss_start and __data_end go in an arbitrary 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 the section of uninitialized data (analog of .bss). It is given as a gift because it is filled with zero bytes. Here are a few auxiliary variables, names that start with timer0_, a global Serial object, and our static local variable.



Small lyrical digression: notice 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 space will not be allocated for it), and secondly, we know that the order of initialization of global objects is not defined, and before entering the main strictly speaking controller not initialized correctly.



At higher addresses is the stack. If the memory capacity of the controller is 2 kilobytes (motherboards based on the atmega328 processor), then the last address will be 0x008008FF. From this address, the stack begins and it grows towards decreasing addresses. There are no barriers, and in principle the stack can crawl onto variables, spoiling them. Or the data can spoil the stack - as lucky. In this case, nothing good will happen. You can call this an undefined behavior, but it's always best to keep enough space in the memory for the stack. How much is hard to say. That is enough for local variables and frames of the stack of all calls, plus for the most difficult interrupt handler with all the nested calls. I, frankly, did not find a more or less honest decision on how to diagnose stack usage.



Let's go back to the code. When I said that the code was stored there, I was a little cunning. In fact, read-only data can also be stored there, but they are extracted from there with a special LPM processor instruction. So, constant data can be placed there and placed for free, because time is not wasted on their initialization. Pay attention to the macros F (...) in the code. They just declare the lines placed in the program memory and then do a little bit of 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 

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



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





A lot, is not it?



And here is the code:





A timer interrupt was involved, 9 bytes to service this timer, and some amount of infrastructure code.



For today, perhaps, enough. I hope someone will find this useful.