/href
Executable Description |
Input Output |
Description |
avr-cpp c preprocessor Full documentation Command line options (this is generic documentation for cpp, not avr-cpp, but it applies just the same) |
myfile.c to myfile.i |
The
C preprocessor. Don't confuse this with the c++ programming
language. A C preprocessor takes all of the
compiler
directives and resolves them. If you want to know how a
preprocessor works to a reasonable but not overwhelming level of
detail, see Kergnihan and Ritchie, The
C programming language, 2nd ed, Sec.A12 in appendix A. A paraphrase of the steps a preprocessor runs, in order, are as follows:
If you want to see the preprocessor output (it really is educational) you can use the following command: avr-gcc -E myfile.c > myfile.i The -E tells avr-gcc to stop after preprocessing and send the output to stdout. |
avr-gcc compiler Command line options (Specific options and compiler implementation for AVR) |
myfile.i to myfile.s |
The compiler. This takes the output of the preprocessor (which is a .i file) and compiles it into assembly language for avr-as to assemble. By the time your code gets to this point, the compiler directives (the things that start with #) have been resolved and turned into actual tokens for the compiler proper (avr-gcc-x.x.x) to translate. In traditional non-AVR GCC, gcc itself is a wrapper that coordinates cpp, an actual compiler like target-gcc-machine, as, and ld |
avr-as assembler The assembler seems to also have the name "gas" (GNU assembler), probably to make is easer to search for becaiuse "as" is a very common word. (Not that "gas" is an infrequent word) : - ) Full documentation Command line options |
myfile.s to myfile.o |
The assembler takes assembly code as input and produces the .o files (object files). Assembly is sometimes hand-written where needed. It is also, strictly speaking, the output of the compiler. The .o files are intermediate files used as input by the linker and librarian. Assembly code is dictated by the instruction set which can be found in the processor datasheet and varies between different classes of processors. Knowing C and using the compiler is good for quickly writing maintainable code which is easily read at a high level, but to really understand the processor, you should know the instruction set. The instruction set is what determines how efficient the compiler will be. The old Z80 instruction set had instructions that would operate on addresses with a constant offset from the stack pointer, which made it efficient for the compiler to reference the stack frame. A Microchip PIC processor, however, will spend lots of time twiddling banking bits and so the compiler will be less efficient. |
avr-ld linker Full documentation Command line options |
myfile.o to image.elf |
The linker produces an image that you can program into a part and have it run. The linker adds startup code to do things like initialize the stack pointer, copy the initial value of all of those initialized variables from flash into RAM where they can be changed, etc. It will also want to see a main() function defined which the startup code will call when it is done. If you want to create a library, see the librarian, avr-ar. The linker is not for creating libraries. avr-ld does use libraries, however to produce an image. |
avr-ar Librarian Top-level docs Command line options |
myfile.o to libmyfile.a *the lib is not optional* |
The "ar" is for archive, which is what the .a at the end of a static library filename stands for as well. Archives are collections of functions and data that are taken from a .o files and put together so that they can be linked in. The librarian maintains libraries as well, performing functions like replacing an object |
gmake The GNU make utility Full documentation |
Whatever your makefile is written to generate, usually from myfile.c as input and the final image myfile.hex or myfile.a as output. | gmake takes a lot of experience to get working well. I'll add a tutorial when time allows. There is a lot of documentation on the web about it. |