We write program in text editor so what happen what's object code? compile generate different files in a project folder How does Atmel studio work to execute c program.
See: https://www.avrfreaks.net/forum/avr-gcc-compiling-linking-and-assembly and look at the diagrams from clawson & me.
How does Atmel studio work to execute c program
Atmel Studio does not execute C programs!
you download them to your target, and the target executes them.
google "cross compiler"
You write .c (or if C++ maybe .cpp). When you "build" this is first passed to the compilation tools. There are two phases to that. First a preprocessor will process the files and replace all the #include and #define (and other preprocessor commands) with their expanded text. The output of that is written to a new file with a .i extension (usually this is "hidden" in a temporary directory and erased at the end of the build).
Next this .i file is passed to the actual C/C++ compiler. That is effectively an "Asm code generaror". So it converts the C/C++ you wrote into the assembler code of the processor you are building for (actually internally it first converts the C/C++ to a generic intermediate language format and then that is passed to a CPU specific code generator). The output of this compilation phase is written to a new file (again usually hidden) with a .s extension which is now in assembler source code format (obviously for avr-gcc this means AVR assembler).
Next the .s file is passed to an assembler in the "binutils" (binary utilities) for the specific CPU so in the case of AVR this will be avr-as which is the AVR specific version of the GNU "as" assembler. That turns the AVR mnemonics into bytes (well words actually) of AVR code. This is where "object code" first appears. The output of this phase is actually in ELF (executable and linkable format) files. At this stage convention dictates the files are given .o extensions (.o = object). In the ELF format there's more than just binary opcodes generated. The files typically have many different sections with all different kinds of data. A lot of the sections are additional information that will later help the code to be debugged (so it might say that in the binary bytes 100 to 118 were generate by lines 3..4 in the source file, it will also store in another section details of the source files). The actual AVR code is just (generally) stored in one subsection of the ELF object file called ".text".
Each .c/.cpp file in the project goes through this same process and each produces different ELF "object" files. But at this stage the file are "unlinked". So say you had started with main.c and it created a main.o and in that code there was a call to UART_init() but UART_init is in a separate .c/.o file then in the first file the "CALL UART_init" will actually be recorded as a "CALL 0" because nothing, at this stage, knows where UART_init is located (or even if it exists at all). Such an entry in the file is known as a "fixup" or a "relocation" and yet another section in all these separate .o files ("object") records "RELOCS" which are things which are "not known yet".
Finally a new tool "ld" which in the AVR case is therefore known as avr-ld is invoked. This is the "linker". It does what it says on the tin - it "links" files together. So you invoke it to maybe say that for your project you want to link together main.o, uart.o, adc.o and timer.o so it reads all the separate object (.o) files for each of those and reads out all the "public" symbols and builds a long list of them. It then starts to make a joined copy of all the different .text sections in a final, output .text section and, as it does this, it makes a note of where each item in the files is being positioned in memory.
So this is the point at which that UART_init from earlier is positioned at some final location. Now that the address of UART_init is known it can go back to the RELOCS for main.o ad find where the "CALL 0" (which is really a CALL UART_init) is located and it updates the destination of the call to the now known location of the function. This is "linking" in action. It is linking the calls from one file to the actual implementation of the functions in another file. Finally this combined image, together with the combined debug info and various other sections from all the individual object files are now put together in one final ELF file. This time, to distinguish that this is now "linked" the file is written with a .elf extension. It's still "object" but it is the combined and linked object of all the previously separate object/ELF files. That then is the AVR program you have created.
All that remains now (because, apart from debugging, ELF contains "too much information") one final process is performed to just extract one small part of the ELF object for programming into your AVR. At this stage a utility called objcopy (so in the AVR version "avr-objcopy") is invoked to just pull (usually) two sections from the combined .elf file. The sections called .text and then .data are taken from the combined .elf and then converted into Intel Hex format as a .hex file (another section from the ELF object called .eeprom may be extracted to another Intel file (.eep) if there's also initial data for the EEPROM).
Bottom line: two "object code" involved - one unlinked in .o files and one linked in the final .elf file
(oh and if you specify the -save-temps build flag (for which AS7 also has a tick box) when you build then those "hidden" .i and .s files are left behind (in the Debug/Release directory) when you build so you can study them and see what's going on. The .s file (asm) can be particularly interesting!)
Bloody hell Cliff - that was a dense bit of info dump :o
Nobody likes a show off.....
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman
"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?" - Lee "theusch"
Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-) - Source Unknown
Please Read: Code-of-Conduct
Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user
I'll vote for that. A little work on formatting and the bot will be done.
my projects: https://github.com/epccs
Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work
Paragraph breaks added.
© 2020 Microchip Technology Inc.