MSP430F5529: Can we enable nano specs in newlib c? How to get a smaller formatted print?

sprintf() and the stuff it drags in is big. But not 83kB big.

Yes I agree - thats why I posted the actual linking instruction I'm using - as suspect I've missed something. If it helps here is the code that gives a ~90kB hex file:

  uint16_t busy0=HWREGW( ADC12_A_BASE | OFS_ADC12CTL1 )&ADC12BUSY);
...
  sprintf(print,"%i%i- \0", busy0,
  	  HWREGW( ADC12_A_BASE | OFS_ADC12CTL1 )&ADC12BUSY);

And same code that gives 6kB hex code

  print[0]='0'+(HWREGW( ADC12_A_BASE | OFS_ADC12CTL1 )&ADC12BUSY);
...
  print[1]='0'+(HWREGW( ADC12_A_BASE | OFS_ADC12CTL1 )&ADC12BUSY);
  print[2]='-';
  print[3]=' ';
  print[4]=0;

Which is why it make little sense to me, so I assume I've got my linking wrong!

Oh yes also worth saying Intel hex encodes each target byte in 2 ihex bytes - so the size different in the target is only ~40kB

Rather than go by hex file size, use msp430-elf-size. I see nothing wrong with the arguments to gcc. My usual is:

CFLAGS = -g -mmcu=${CPU} -I $(SUPPORT_FILE_DIRECTORY)  -Wall  -Wl,--gc-sections

When I add an sprintf call, using a floating point format, the size increases by about 6kB.

That device has 128kB so your code should fit even with that bloat. Assuming you compiled with "-mlarge" of course.

Yes I usually go from the hex file sizes, as the hex file is stripped. The elf file I don't usually strip, but doing so the two sizes are:

-rwxr-xr-x 1 summers summers 3380 Apr 25 12:07 gcc/sinlookupuart2048.out
-rwxr-xr-x 1 summers summers 33080 Apr 25 12:09 gcc/sinlookupuart2048.out

So you can see its adding about 30kB of actual size on the box. The object files are almost exactly the same size. Think its the linking flags that I need isn't it - its only during linking to libc that I get the bloat.

And just tried the size command thats interesting

   text	   data	    bss	    dec	    hex	filename
  29974	   1850	    212	  32036	   7d24	gcc/sinlookupuart2048.out

So most of the size is in text from the libc! How odd.

Although since it is an .elf file, the regular Linux bintools version of size works as well. Both also work on your .o files as well.

There are many tools available to examine the elf file. "msp430-elf-readelf -a" will display information about it and "msp430-elf-objdump -S" will disassemble it. Both should provide some hint as to where the extra code is coming from.

Plus you can tell the linker to output a map file showing where it puts things. And where it got them. Perhaps more information than you want.

Add this to the gcc options: -Wl,-Map=yourfilenamehere.map