• Not Answered

Code optimization

Hi all,

 

I'm getting started to code development for MSP430 (currently for g2231, launchpad) and CCSv4. I'm trying to debug a simple application that I've written which is split  into several files. When I compiled my program first I got an error relative to its size (bigger than the flash!) and I cannot understant why this can happen cause the functions are really simple, basically read/write i2c and handle IO interrupts. Using highest level of optimization I can get to download the binary to the MCU and debug the application though I guess I am missing something. Have looked carefully at the optimization options and tried many but with similar results (image still too big for code complexity). Checking the map file I see that no dead code is included (I cannot see what happens at other levels of optimization cause the map file doesn't include that information in such cases) and I find symbols that have to come from the RTS lib, could this be adding such extra-weight to the image? How can I make sure everything included is essential? Can that be controlled anyhow?

Thanks in advance

Best regards

7 Replies

  • If you used the c library (intentionally or unintentionally), that could use a lot of memory.

    Try the "simple" program and see how much memory it uses.

    void main ( void )

    {

       pfintf ( “Hello, world!\n);

  • In reply to OCY:

    jezule
    I'm getting started to code development for MSP430

    Do you have any prior experience with any other microcontroller(s)?

    Do you have any prior experience with programming in general?

    jezule
    I cannot understant why this can happen cause the functions are really simple (sic)

    Most likely, this is because you have failed to appreciate how much "background" code it takes to make these functions appear "simple"...!

    Lichen Wang88934
    Try the "simple" (sic) program and see how much memory it uses. 
    void main ( void )
    {
       pfintf ( “Hello, world!\n);

    This is a clasic example of something which appears "simple" (ie, it has only a few lines), but is actually not at all!

    printf() is a very complex and powerful function indeed - therefore, it can take up a very large amount of code space!

    (some compilers are smart enough to spot that you only use a little of the printf functionality and, therefore, only include that part - but don't rely on it...!)

    Another very common pitfall is the use of floating-point arithmetic...

  • In reply to Andy Neil:

    Hi all,

    Yes, I do have experience programming microcontrollers, specially AVRs using C. Also did something with TI C2000 and CCS long ago.

    I say that they are quite simple because I do not do anything that requires lot of processing power such as floating point math. Not using printf either, I have even removed support for it from the compiler options. Basically I have some functions to R/W I2C, interrupt driven, based on the code examples and wrappers that call this functions with different arguments, that's all. I'm trying to have a closer look at how the C code is translated to assembly to see what it is taking so much space, maybe I'm not following right coding guidelines. For example, for AVR you can use avr-nm to find out how much space functions and symbol take. Any tool similar for MSP430? I cannot know when the text section is not being allocated due to lack of space.

    In the map file I could see references to symbols such as div16s, lsl16, div16u or memcpy that honestly don't know why they are included.

    I'll review everything on Monday.

    Regards

     

  • In reply to jezule:

    jezule
    ... code development for MSP430 (currently for g2231 ...

    Do you mean MSP430G2231 ?

    http://www.ti.com/product/msp430g2231

    Note how the forum automatically makes a clickable hyperlink when you give the full part number.

    You do realise that this part has only 2K of flash and 128 bytes of RAM...?

  • In reply to Andy Neil:

    Yes, I do realize. The target processor is a G2312 (or G2412 don't remember now) but until I get a development board I'm using the Launchpad with a G2231.

    Actually RAM is no way full, still "plenty" space. I'm just running out of Flash and I try to determine if this makes sense or I'm doing something wrong regarding compiling/linking. I think that with 2K, given the program complexity, shouldn't be having such problem though I might be wrong, of course.

    Regards

  • In reply to jezule:

    jezule

    In the map file I could see references to symbols such as div16s, lsl16, div16u or memcpy that honestly don't know why they are included.

    memcpy  gets included as soon as you initialize some array with data but not as const, it will be copied from the flash to the ram before main is executed. It takes around 100 bytes of code. (uint array[10] = {1,2,3,4,5,6,7,8,9,10})

    div16s - seems to be a 16 bit signed division, again ~90 bytes. ( int foo = int bar / int thing)

    div16u - same for unsigned division, ~40 bytes. (uint foo = uint bar / uint thing)

    lsl16 - logic shift left for 16 bit ~30 bytes. (uint foo = uint bar << uint thing)

     

    So you see even very simple (even without printf and other high class functions) 4 lines of code can produce a significant amount of flash needed.

    I was also surprised by this at first but you can find the culprits in your code (include your files one by one and see when the size gets bigger by far what you'd expect). Then you can try and think of something smaller or more elegant, sometimes you'll have to change your algorithm for that.

  • In reply to Bernhard Weller:

    Hi,

    This morning I've updated to CCSv5 that comes with a newer version of the compiler and things have improved. I have changed to EABI as output format as well. Now, for example, div16s, div16u and lsl16 do not appear in the map file anymore. I'm using the map file to see which parts of my code take more space and trying to reduce them, trying to learn how the compiler optimizes and how to optimally code for msp430. The text section is 1776 bytes now but I think that I can still reduce it more without moving to assembly.

    Regards