The Arduino IDE reads the INO (or PDE) file and creates a '.cpp' file from it, making some additions here and there and deriving the correct include paths so that it can invoke avr-gcc and compile the program. it basically parses the INO script, looking for #include <library.h> (whatever library you include) so that the correct file(s) will be built and linked in with your code. If you want a hint as to what's happening, go to the settings and enable 'verbose output' for compiles. then check out the compiler command lines, and all of the '-I' paths and the actual files it's reading and writing to. You get copies of the library source that's compiled with your device's settings [this is necessary] in addition to your own source. that's what the Arduino IDE is doing for you, basically, when you include things like Wire.h or a custom library (like Sparkfun's motor controller library).
In any case, you should study what the Arduino IDE is doing to build your application.
[personally I think autocomplete is overrated, and I usually turn it off because I don't like irritatingly long pauses while I type, but that's just me]
avr-gcc will have been compiled with some pre-defined include and link paths already. You can find out what these are with the following command:
avr-gcc --version -v
that should give you all of the path info [although it's a bit cryptic]
The Arduino IDE reads the INO (or PDE) file and creates a '.cpp' file from it, making some additions here and there and deriving the correct include paths so that it can invoke avr-gcc and compile the program. it basically parses the INO script, looking for #include <library.h> (whatever library you include) so that the correct file(s) will be built and linked in with your code.
I'm doing the same - adding "#include <Arduino.h>. I've compiled Blink sketch and found Blink.cpp in build folder.
If you want a hint as to what's happening, go to the settings and enable 'verbose output' for compiles. then check out the compiler command lines, and all of the '-I' paths and the actual files it's reading and writing to. You get copies of the library source that's compiled with your device's settings [this is necessary] in addition to your own source. that's what the Arduino IDE is doing for you, basically, when you include things like Wire.h or a custom library (like Sparkfun's motor controller library).
I've learned it first and i can't understand where such definitions are.
In any case, you should study what the Arduino IDE is doing to build your application.
[personally I think autocomplete is overrated, and I usually turn it off because I don't like irritatingly long pauses while I type, but that's just me]
avr-gcc will have been compiled with some pre-defined include and link paths already. You can find out what these are with the following command:
avr-gcc --version -v
that should give you all of the path info [although it's a bit cryptic]
The problem is not to compile - i do understand that it compiles all core files, then archieves it, copies objects and finally link to binary file. For autocomplete i can't compile object files and link them, i need to build right command line with "-I" taking into account all family inclusion rules and so on
what header files should be included first for each board type?
The various hardware register definitions come in through the "#include <avr/io.h>" statement in Arduino.h.
io.h in turn includes one of the many io*.h files from avr/include/avr, depending on the setting of the -mmcu switch on the compile statement. These in turn are automatically generated from xml "device description" files provided by Atmel.
So if you say -mmcu=atmega328p, you'll get iom328p.h sucked into your program, which defines all of the hardware registers "and stuff, and support" that are present on the ATmega328p.
You can read a statement like: "#if defined(UBRRH) || defined(UBRR0H)" as "if there is a single UART, or there is a UART0, then (create the datastructures arduino uses for dealing with the first serial port.)"
As of relatively recently, most of the arduino core code will check for the existence of particular peripherals by looking for the definition of a significant register from that peripheral, rather than doing conditional compilation based on board or cpu type.
So on an Arduino MEGA, the code will define data for Serial3, not because it's a MEGA, or because it has a m1280 cpu, but because UBRRH3 is defined, which means that "elsewhere" knows that a UART3 exists...
PS: this also means that io.h pulls in a LOT of register definitions that you probably do NOT want to add to your autocomplete word list for the average Arduino user!
what header files should be included first for each board type?
The various hardware register definitions come in through the "#include <avr/io.h>" statement in Arduino.h.
io.h in turn includes one of the many io*.h files from avr/include/avr, depending on the setting of the -mmcu switch on the compile statement. These in turn are automatically generated from xml "device description" files provided by Atmel.
So if you say -mmcu=atmega328p, you'll get iom328p.h sucked into your program, which defines all of the hardware registers "and stuff, and support" that are present on the ATmega328p.
How is that correlation done? Will that work only with arduino gcc toolchain from desktop distribution or with another too (Clang f.e.). Let's say i using clang which support gcc arguments. will that work with it or arduino toolchain knows somehow the correlation and it's not presented in the sources (headers)? I'm asking because i already pass mmcu argument and it does not work in my case, so i assume that my current toolchain (not gcc and not arduino gcc) does not have such correlation rules or smth.
You can read a statement like: "#if defined(UBRRH) || defined(UBRR0H)" as "if there is a single UART, or there is a UART0, then (create the datastructures arduino uses for dealing with the first serial port.)"
As of relatively recently, most of the arduino core code will check for the existence of particular peripherals by looking for the definition of a significant register from that peripheral, rather than doing conditional compilation based on board or cpu type.
So on an Arduino MEGA, the code will define data for Serial3, not because it's a MEGA, or because it has a m1280 cpu, but because UBRRH3 is defined, which means that "elsewhere" knows that a UART3 exists...
PS: this also means that io.h pulls in a LOT of register definitions that you probably do NOT want to add to your autocomplete word list for the average Arduino user!
Thank you for great and clear explanation! One more question to solve is to build correct -I paths list. I have avr/avr-3/avr-4 folders that have exactly the same files list in each of them. Which one should i use in -I paths or should i just add all of them?