• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 304 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

David Fishman
Intellectual 475 points
Part Number: MSPM0G3507-Q1

Tool/software:

Hi,

After adding the stdio library and one sscanf command the code memory size requirement incresed by 46kB.

I'm using a GCC compiler. Optimization for space helps a litte.

Is this to be expected? Can something be done to reduce this overhead, such as remove unused functions from the library?

I need space for my application :-).

Thanks,

Dave 

  • 0
    Guru 41795 points

    Write your own parsing routine. The linker already only includes the functions you use,however, there may be many subfunctions that sscanf() calls that are used by other stdio() routines.

    You might be able to find a version of sscanf() on the net that you can pare down and modify to your own purposes.

  • 0
    Intellectual 475 points

    Thanks Keith.

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

  • 0 in reply to David Fishman
    Guru 41795 points

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

  • 0 in reply to Keith Barkley
    TI__Genius 15490 points

    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.

  • 0 in reply to Dylan OBrien
    Intellectual 475 points

    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. 

  • 0 in reply to David Fishman
    Guru 41795 points

    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)

  • 0 in reply to Keith Barkley
    TI__Genius 15490 points

    We don't have plans to further optimize this. Particularly for MSPM0 devices with their smaller memory, we don't anticipate many customers using stdio functions. We also recommend that our users avoid them.

  • 0 in reply to Dylan OBrien
    Guru 94630 points

    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.

  • 0 in reply to Bruce McKenney
    Intellectual 475 points

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

  • 0 in reply to David Fishman
    TI__Genius 15490 points

    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.

  • 0 in reply to David Fishman
    Guru 94630 points

    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.

  • 0 in reply to Bruce McKenney
    Intellectual 475 points

    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

  • 0 in reply to David Fishman
    Guru 41795 points

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

  • 0 in reply to Keith Barkley
    Intellectual 475 points

    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.