Go Down

Topic: binary sketch sizes + Serial com..... (size tuning?)[SOLVED] (Read 1 time) previous topic - next topic

alexander_senseo

Mar 09, 2013, 10:49 am Last Edit: Mar 09, 2013, 01:55 pm by alexander_senseo Reason: 1
Firstly: I wanna mention, that I have tried to find some useful data myself... but I was not very much successful.

The size limitations impossed by the atmel chips on the arduino boards make me care about "binary sketch size" (btw. is there a more general term to the size of the compilation+linking output)?

The binary sketch size of the blink example for instance is "meager"(small) (1222 bytes)

ofencito@freak:~/Desktop/arduino/blink$ avr-size program.hex
  text      data       bss       dec       hex   filename
     0      1222         0      1222       4c6   program.hex


As soon as I edit the setup() function to include a Serial.begin(9600); like this:

Code: [Select]
void setup() {                
 // initialize the digital pin as an output.
 pinMode(led, OUTPUT);    
 Serial.begin(9600);
}


the "binary sketch size" almost explodes in size and goes ab to 14'864 bytes:


ofencito@freak:~/Desktop/arduino/blink$ avr-size program.hex
  text      data       bss       dec       hex   filename
     0     14864         0     14864      3a10   program.hex


Of course I expected that the Serial communication increases the size somewhat.
Still an about 1100% increase seems a little suprising to me.
This is mainly because I know that while the ATmega328 chip on the Arduino Uno can easily accomodate/store
this easily (it has 32'000 = almost twice the memory) I wonder how this size would have worked with most
of the other models that only came with 16k or 8k???

Since I assume there must have been a communication Serial also in the 8k version, but the 8k would of course
not be able to store the resulting about 14.8k of data I wonder if the 14.8k size is really right, or I am just
doing some wrong linking etc.

Maybe somebody can give me a glue what to use as compiler and linker flags.....

Also it would be nice if somebody would be able to test if the modified setup() function
also causes about a similar size of 14.8k "binary sketch size"??

Nick Gammon

What are you doing exactly? What Arduino is it? What version of the IDE do you have?

Code: [Select]

void setup() {                
 pinMode(13, OUTPUT);    
 Serial.begin(9600);
}

void loop () { }


That gives me, for the Uno on 1.0.3 of the IDE:

Code: [Select]

Binary sketch size: 1,968 bytes (of a 32,256 byte maximum)


So that is hardly 14K bytes.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

alexander_senseo

#2
Mar 09, 2013, 11:39 am Last Edit: Mar 09, 2013, 11:52 am by alexander_senseo Reason: 1
Thank Nick for the quick reply! :)
First of all it's been really nice of your to have tested and posted the "binary sketch size" here. thank you for that.

Quote
What are you doing exactly?(a) What Arduino is it?(b) What version of the IDE do you have?(c)


I am sorry if I have left my post without this informaiton. Thank you for asking.

(a). I have not been doing something very specific, but rather have noticed that I have this huge increase in "binary sketch size" as soon as I start using the Serial communication. So I asked this question... while indeed it was not linked to (yet) a very specific problem, but rather because of my suprise and lack of understanding. I hope this is ok!
As it seems my suspicion that this increase to a size of 14.8k is too much, was correct as your test showed me.

(b) it is an Arduino Uno that I am using. It is true that there is already quite a variaty of Arduinos and when I wrote that I have the ATmega328 microcontroller, well I might have not been specific.. ,wasn't I? (sorry!)

(c) I do actually not use the IDE provided on the side at all, but instead I have used the http://arduino.googlecode.com/files/arduino-1.0.3-linux32.tgz package (of the 1.0.3 IDE), which includes the files for development (without IDE and most importingly JAVA) inside at:

  • (general files) hardware/arduino/cores/arduino 

  • (UNO pins) hardware/arduino/variants/standard/pins_arduino.h


from those I made a library which I link against. I use the avr-g++ version "avr-g++ (GCC) 4.5.3".

I dearly love not to use the IDE because in this way I am more involved in the process of creating/builing the acutal binary and uploading it to the Arduino UNO. Also I do not have, neither plan and desire to have, JAVA on my machine for various reasons. It is nice to have the IDE, but I do not require it particularily much as I use one I am quite accustomed to named (Geany).

Now I am still at a loss to figure out how my approach yields me such a much higher "binary sketch size"

Any ideas?

alexander_senseo

Simply to answer my original post and especially the part about size tuning.

First the my result (still not using the IDE) I have yielded an optimized size for the "setup()" modified blink example of 2262 bytes only:
avr-objcopy -O ihex program.elf program.hex
   text      data       bss       dec       hex   filename
      0      2262         0      2262       8d6   program.hex

For the example as used in the post of Nick (with an empty loop) I even have smaller 1852 bytes. So the results are good now.

The (how to) size tuning information I have asked for in the post is done (as suggested already by using compiler and linker flags).
For generating the libarduino (from the source found in the 1.0.3 IDE package) I have used those compiler flags:
-Os -w -Wl,--gc-sections -ffunction-sections  -fdata-sections

When compiling the final sketch I have then used those compiling flags (which incitently are the same):
-Os -w -Wl,--gc-sections -ffunction-sections -fdata-sections

The reason for the previously huge 14.8k has been that the library was not compiled with the
-Wl,--gc-sections -ffunction-sections -fdata-sections flags which did not
detach the functions within the library, meaning that Serial.begin(9600) linked in from the library
caused many other entangled functions to be linked in too, though never used. With the flags
-Wl,--gc-sections -ffunction-sections -fdata-sections added to the compilation of
the libraray this detached the functions into own objects which can be hence linked seperatly on a
"each one only when needed"-basis.
This reduced the code from 14.8k to 2262.

I hope people reading this, mostly those also shunting the IDE will benefit from this explenation given.
Since those people not using the IDE often by requirement have to know somewhat more, it might not
even be necessary for those "advanced" developers, but anyhow. There is no loss or harm caused by giving
a more fitting answer to the question or post. It might actually assist and helpe somebody.... who knows?

PeterH

If you bypass the Arduino IDE and compile and link your software yourself, then you take responsibility for specifying the appropriate options. It should not come as any surprise to find that if you don't apply the appropriate optimisations then the output is not optimal.

Also note that you have been looking at the size of the image file, which is not the same as the number of bytes of program memory used by the sketch.
I only provide help via the forum - please do not contact me for private consultancy.

spatula


...
First the my result (still not using the IDE) I have yielded an optimized size for the "setup()" modified blink example of 2262 bytes only:
avr-objcopy -O ihex program.elf program.hex
   text      data       bss       dec       hex   filename
      0      2262         0      2262       8d6   program.hex

...
When compiling the final sketch I have then used those compiling flags (which incitently are the same):
-Os -w -Wl,--gc-sections -ffunction-sections -fdata-sections
...


Just for reference, my own results from a 1.0.3. IDE running on Mac OSX 10.6. The only difference between the two versions is a Serial.begin(9600) in setup().

Code: [Select]

   text    data     bss     dec     hex filename
      0    1084       0    1084     43c Blink.cpp.hex

   text    data     bss     dec     hex filename
      0    2362       0    2362     93a Blink.cpp.hex


The interesting thing is that your optimized code is more optimized than mine. The (default) c flags in my case (some obviously target-specific) are as follows:

Code: [Select]

-c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=103


Nick Gammon


(c) I do actually not use the IDE provided on the side at all, but instead I have used ...


I guessed that from the command-line options you were doing, and of course if you are getting "down and dirty" then the exact thing that you are doing is relevant.

The default IDE compiler and linker options are highly aggressive, resulting in code which is very optimized and also which does not link in code which is not needed.

Even something simple like declaring a large array, and not using it at all, results in the array not appearing in the final code.

Also people may find that even after including lots of libraries their code size does not increase, but once they start calling functions in them, it does.

Thanks for your follow-up posts.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

alexander_senseo


Also note that you have been looking at the size of the image file, which is not the same as the number of bytes of program memory used by the sketch.


That sounds interesting PeterH. Thank you for mentioning this. Can you tell some more about those different sizes. I used the avr-size tool, which I actually thought to be the way to actually see the memory of the sketch used in the flash memory afterwards. Is it not?

What is the "size of the image file"? would that be not the size of the .elf or .hex file then?

alexander_senseo


The interesting thing is that your optimized code is more optimized than mine. [....]


I think that the reason for the difference of 100 bytes is because I do use a different main() function underlying the loop() and setup() functions in the "sketch file".

I have these modifications (the code-lines commented out) in the main():

Code: [Select]
int main(void)
{
init();

#if defined(USBCON)
//USBDevice.attach();
#endif

setup();
   
for (;;) {
loop();
//if (serialEventRun) serialEventRun();
}
       
return 0;
}


Up to now they did not seem to be that very much necessary... but there might be important reasons for them..(I would sure like to know.. thought that is another question)
I assume the skipping of those two lines of code causes the meager size difference of 100bytes (which is almost nothing anyhow)


Nick Gammon

My example above which reported:

Code: [Select]

Binary sketch size: 1,968 bytes (of a 32,256 byte maximum)


... gives this with avr-size:

Code: [Select]
$ avr-size sketch_mar09c.cpp.hex
   text    data     bss     dec     hex filename
      0    1968       0    1968     7b0 sketch_mar09c.cpp.hex


So, it's the same.

The file size is, of course, larger as the data is stored in hex:

Code: [Select]

-rw-r--r--  1 nick  staff  5548 10 Mar 08:42 /sketch_mar09c.cpp.hex


If I do my own main I can get the size down:

Code: [Select]

int main()
{               
  pinMode(13, OUTPUT);   
  Serial.begin(9600);
}


Gives:

Code: [Select]

Binary sketch size: 1,638 bytes (of a 32,256 byte maximum)


Of course, the "real" main does useful stuff, like calling init, which initializes the timer used for millis(), micros() etc.




Minimal sketch:

Code: [Select]

int main()
{               
}


Size:

Code: [Select]

Binary sketch size: 176 bytes (of a 32,256 byte maximum)
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Nick Gammon


Up to now they did not seem to be that very much necessary... but there might be important reasons for them


The USB line would be for the Leonardo.

The serialEvent stuff I would happily be rid of. It's for calling your own function when serial data arrives, as if you can't work that part out for yourself.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

alexander_senseo


The USB line would be for the Leonardo.

The serialEvent stuff I would happily be rid of. It's for calling your own function when serial data arrives, as if you can't work that part out for yourself.


I am much obligued for enlightening me about the purposes of the stuff left in main(). As indeed I already skipped most it anyhow I now have certainty that it was really not a  big loss at all. It speaks my heart, when you say "as if you can't work that part out for yourself". Maybe it is nonetheless a necessary thing for the early beginners, which might otherwise more easily run into a discouraging "I'm stuck"-situation. The people that know about it can easily modify the main.cpp so taht it better caters their needs.

PeterH


That sounds interesting PeterH. Thank you for mentioning this. Can you tell some more about those different sizes. I used the avr-size tool, which I actually thought to be the way to actually see the memory of the sketch used in the flash memory afterwards. Is it not?

What is the "size of the image file"? would that be not the size of the .elf or .hex file then?


I'm sorry, I mis-read your post. I thought you were quoting the file size of the file containing your hex image, not the hex image size as reported by AVR.
I only provide help via the forum - please do not contact me for private consultancy.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy