MSPM0G3507-Q1: Huge increase in code memory size with stdio functions

Thanks Keith.

So you are not surprised that the code size increased by 46kB?

No, because I don't think TI puts much effort into optimizing them. They are also stack hogs.

Hi David,

I can't speak much to the specific increase of 46kB but I can say that we do not recommend utilizing stdio functions as they are memory intensive. For these reasons we do not anticipate our customers using stdio functions. 

Optimization should help, but agreed that if possible, writing your own function here would likely free up a lot more memory.

Hi Dylan, thanks for confirming. I wonder if TI is working on optimizing the stdio functions so that they can be competetive. The code for the MSPM0 was ported from an Infineon PSOC5LP (Cortex M3), and the code memory requirements were much less. 

I doubt it. stdio is of limited usefulness on an embedded "non-hosted" implementation, and TI's shared-memory scheme with the debugger is pretty kludgey. (All IMHO, of course)

I'm not sure I would use such a broad brush.

A .map file for one of my programs which uses snprintf() shows about 5KB (Flash) for the entire program, including about 2KB for printfi (the bulk of Xprintf). I don't use Xscanf, so I don't know about that one.

Thanks to all who responded. Does TI know of a compiler for the MSPM0 devices that optimizes functions in the stdio library? Thanks, Dave

All MSPM0 driverlib examples come with support for gcc, iar, keil, and ticlang. I am less familiar with which compiler is the most stdio-friendly but would encourage you to try a quick test using these other options.

Also to add context, at times I have used stdio functions in my MSPM0 projects, so even though I recommend against it due to high memory usage, I don't do so that expecting that nobody anywhere uses it. Just emphasizing that it has a high cost that is particularly critical in devices like MSP. Also many people, including myself not that long ago, did not know the drawbacks of using stdio in low memory embedded applications.

A fair amount of effort has been expended in streamlining Xprintf in particular, so it can be as small as it can get away with. I wonder if the same effort has been expended on Xscanf. 

In particular, I wonder if using sscanf pulls in a big chunk of the floating point support (whether you asked for it or not). If you have the patience, the library source is available in <ccsversion>/ccs/tools/compiler/ti-cgt-arm_<version>/lib/src.

Hi Bruce,

I just ran a test with some floating point expressions (*, /, log, log10, sqrt, +, -). I had none before. These added ~6kB to code memory.

So it doesnt seem like sscanf is pulling floating point support. Would you agree?

Thanks,

Dave

Not if you had left sscanf() in there. The point is that sscanf() is pulling in the support.

Good point Keith. 

I commented out all sscanf and sprintf commands and the FLASH requirement with and without the floating point expressions (*, /, log, log10, sqrt, +, -), differed by 13kB. So you're assertion appears to be true.