Print library is to big

If you need the Print library only for some debugging messages with bytes (char, uint8_t) you can save easily 4500 bytes !! if you delete some print(), println() and printFloat() methods. Therefore I have a definition "#define extendedprint" added in my code and exclude this procedures.

A better way could be a standard "PrintBytes" library and a second "PrintExtended" library.

Not sure how you are saving 4500 bytes. A simple sketch that prints a character to the serial port uses less than 1300 bytes.

void setup() 
{ 
  Serial.begin(9600); 
}

void loop() 
{ 
  Serial.print('a');   
}

What version of Arduino are you using? The older releases linked in lots of unused code. Try the standard print library with the latest release.

Yea, Im not seeing 4500 bytes either. I have 1332 for print()ing a byte and 3154 for println()ing a float. Could you elaborate?

//byte floater=125;
float floater=125.6;

void setup(){
  Serial.begin(9600);
  Serial.println(floater);
}

void loop(){}

While on the topic of Print library. Why do this class not use template functions for print and println ?

There was some discussion on templates for print in this thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1231224786/0

Hello “mem”, hello “knuckles904”,
How can I save 4500 bytes if the complete code have only 1300 bytes :o? Your arguments are very good!

I’m using not arduino but eclipse. I link all object files “manually”. I see the following output for “big” Print:

Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex 002_ArduinoCores.elf  "002_ArduinoCores.hex"
Finished building: 002_ArduinoCores.hex
 
Invoking: Print Size
avr-size --format=berkeley -t 002_ArduinoCores.elf
   text         data          bss          dec          hex      filename
   6574          272          162         7008         1b60      002_ArduinoCores.elf
   6574          272          162         7008         1b60      (TOTALS)
Finished building: sizedummy

…and this output for my “small byte” Print

Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex 002_ArduinoCores.elf  "002_ArduinoCores.hex"
Finished building: 002_ArduinoCores.hex
 
Invoking: Print Size
avr-size --format=berkeley -t 002_ArduinoCores.elf
   text         data          bss          dec          hex      filename
   2218            6          162         2386          952      002_ArduinoCores.elf
   2218            6          162         2386          952      (TOTALS)
Finished building: sizedummy

The difference I see is 4622 bytes.

My c-code is the same like yours.

In my opinion something go wrong with output of hex-size at me or at your’s site.
How we can do a really compare our hex-files with each other?

There is a *.hex file which has 6281 bytes for “small” and 19269 bytes for “big” one - I’m confused.

I would guess that the compile and link options you are using are not the same as used in the arduino IDE. Also check you are using the same version of the toolset

I don't know if you can change the description of this thread, but if the issue you have is because you are not using the Arduino IDE then you should change the title or add some text to make clear that this is Eclipse specific.

This issue is not relevant for the typical Arduino user

Arduino libraries are not standard ar libraries (libXXX.a), but simple object code files. Executable size is reduced with some linker options to remove unused code.

-j

Bear in mind too that .HEX files are at least twice as many bytes as the binary.

Hello all! @mem: 1.) Where can I find the compile options for arduino - I have installed the Arduino 0015 2.) I'm using avr-gcc-4.4.0, complete toolchain installed under Gentoo 3.) I'm not sure about that don't affect arduino- I repeat my question: Which file we can compare to get the right information of size? Where is the location of hex-file (or "elf") from arduino? Than I could upload this by hand with avrdude. I can compare this by myself with "0015" and "eclipse".

@kg4wsv: Simple object code files have the extension ".o"? Eclipse aka gcc/g++ do so.

@EmilyJane: This would be good: the difference divided by two is ca. 6500 bytes, ok - not quite good

Thanks for your active replys Gentoo-Thomas

1.) Where can I find the compile options for arduino - I have installed the Arduino 0015 There is a makefile in the hardware/cores/arduino directory

2.) I'm using avr-gcc-4.4.0, complete toolchain installed under Gentoo Not sure what version is currently being used, I think its 4.3.2 but you may find the information in one of these links: http://www.arduino.cc/en/Hacking/HomePage

3.) I'm not sure about that don't affect arduino- I repeat my question: Which file we can compare to get the right information of size? You get the number of bytes of flash needed for an Arduino compiled file displayed in the IDE. Its also in the elf file and if you search for avr-dump.exe you can use this tool to get lots of information about the compiled code

Where is the location of hex-file (or "elf") from arduino? Than I could upload this by hand with avrdude. I can compare > this by myself with "0015" and "eclipse". The elf file is in the applet directory, just below the directory with the sketch source code.

I think you are missing the point. In a sketch I just compiled, it produced 6054 bytes of binary. That is how much program storage will be required. The .hex file for that sketch is 15,520 bytes. That is the size of the file that the chip programmer uses. It uses 2 ascii characters for each binary byte + about 10 ascii characters overhead for every 32 characters to transmit.

If you are basing your judgement of the size of the print library based on the size of the .hex files, then you are making a big mistake.

We use command line arguments to gcc, etc to remove unused functions from the generated .hex file. To see the command lines used, set build.verbose to true in your Arduino preferences file

Hello all! First the most important: THIS IS NOT A PROBLEM IF YOU USE THE ARDUINO ENVIRONMENT!

I'm not completely sure about the cause of problem in my eclipse environment.

@mem: avr-dump.exe is not in my environment (linux) but

avr-size --format=berkeley -t AnElfFile.elf

will do some good jobs. The values in the "text" column match the scetch size printed from arduino except 2-4 bytes plus or minus.

The simple Serial.print example shows me 1290 at arduino and 1284 from "avr-size".

@mellis: Thank you for that advice. I have used now the same compiler and linker options like arduino. My own example generated from eclipse shows me 6942 (normal, not my "shortprint") - thats disturbing.

If I have found the cause of that I will reply the solution here.

and ... no, I can't modify the old posts anymore.

I think you can be clearer than that. "NOT ARDUINO specific" can imply that the problem can relate to the Arduino environment.

As this is not the case I think you can say: THIS IS NOT A PROBLEM IF YOU USE THE ARDUINO ENVIRONMENT

(Normal people can ignore this message!)

/Applications/arduino/arduino-0016/hardware/cores/arduino/wiring_shift.c -o/tmp/build6607.tmp/wiring_shift.c.o
hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega168 -DF_CPU=16000000L -I/Applications/arduino/arduino-0016/hardware/cores/arduino /tmp/build6607.tmp/Temporary_6327_9221.cpp -o/tmp/build6607.tmp/Temporary_6327_9221.cpp.o

hardware/tools/avr/bin/avr-gcc -Os -Wl,–gc-sections -mmcu=atmega168 -o /tmp/build6607.tmp/fastwrite.elf /tmp/build6607.tmp/Temporary_6327_9221.cpp.o /tmp/build6607.tmp/core.a -L/tmp/build6607.tmp -lm
hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build6607.tmp/fastwrite.elf /tmp/build6607.tmp/fastwrite.eep

Here are representative compile and link commands from the Arduino IDE build process. The pieces your eclipse build is missing are probably the pieces that I’ve made bold. In the compile “-ffunction-sections” causes each function to be put in its own linker section, and in the link I’m pretty sure that “-gc-sections” causes the linker to garbage collect (omit) any section that isn’t referenced from somewhere else.