Go Down

Topic: Understanding arduino innards - WProgram.h (Read 2403 times) previous topic - next topic


during the build process, WProgram.h (/usr/share/arduino/hardware/arduino/cores) is added to the sketch. i am trying to count the lines of code that contribute to the .hex file.

if my sketch does not include any other libraries, is it safe to say that all the code that is used to produce the .hex file comes from my sketch and all the code in the /usr/share/arduino/hardware/arduino/cores directory?  did i miss anything else?

some of the header files in the that directory includes other header files outside /usr/share/arduino/hardware/arduino/cores

thanks a lot  ::)


i am trying to count the lines of code that contribute to the .hex file.

For what purpose? Some of the code is in the form of pre-compiled object files for which you may not have source code available.
The art of getting good answers lies in asking good questions.


for which you may not have source code available

Oh? I thought Arduino was a fully open source system   :-?


I thought Arduino was a fully open source system

It is. But, all that means is that source is available. It does not mean that the source code is all installed locally on my, or your, machine.
The art of getting good answers lies in asking good questions.


Jul 13, 2010, 04:14 pm Last Edit: Jul 13, 2010, 10:11 pm by davekw7x Reason: 1
You can try this:

Make an do-nothing program (empty main() function). Compile from command line with avr-gcc.  Use the same compiler switches that Arduino uses.

Then include WProgram.h and compile again

When you include  <WProgram.h> in a "normal" sketch it supplies protypes for a main() function and an init() function which will be linked into the executable, but there is no added executable code or data storage due to <WProgram.h> itself (and the headers that it includes). When you compile this sketch from a command line, it doesn't link in the any of the core object files. (See Footnote.)


Since some of the Arduino core header files define C++ classes, the compiler/linker does put in some extra stuff for the C++ classes (stuff like vtables).  This stuff is not code from the core object files; it is internal bookkeeping stuff that the linker thinks the program might need.

Try  the following with any standard C++ compiler on your workstation.  Compile a do-nothing C++ file (containing absolutely nothing other than an empty main() function).  Then include <iostream> and compile again.  The resulting (do-nothing) executable is larger (probably by a few hundred bytes) when you include a header that defines C++ classes, even if your program don't use the classes to create objects.



Footnote: The main() function for a "normal" Arduino sketch is obtained from the core function main.cpp, and contributes a few bytes since it calls three functions and has a for loop
Code: [Select]
#include <WProgram.h>
int main(void)
   for (;;)
   return 0;

Look at core file wiring.c to see what init() contributes.

None of the header files themselves contribute any data definitions or executable code to the .hex file.  Note that even though the Arduino build process shows all of the object files from the core library files when it builds a library from the core object files, the only ones that get linked in (other than the object files from main.cpp and wiring.c) are ones that contain functions that are used by your sketch.

Bottom line: For a "normal" sketch, including <WProgram.h> always adds stuff from main.cpp and wiring.c when the sketch is linked.  Other stuff is put in by the avr-gcc linker.

Postscript to bottom line:
If you want to see how many bytes are in an absolutely minimal sketch, try the following:

Code: [Select]

int main(){}

That's not a misprint: The whole sketch consists of an empty main() function.  (No setup(), no loop(), just this main() function.)

When Arduino links all of the files, this main() function is used (not the one from the Arduino core main.cpp), since the object file from the cpp created by the sketch has already been linked by the time that the linker encounters the library built from core object files. Therefore the resulting executable consists only of avr-gcc runtime code.

Now, even though many of the readers, if any are left, are (probably) exhausted by now, this is not an exhaustive treatment of the subject.  Just a few ideas for things to try if anyone is still interested (and is still awake).


nice. the footnotes are useful too. i will try them when i'm more awake later.... thank you!!

Go Up