Code optimization

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);

} 

jezule said:

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 said:

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 said:

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...

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

jezule said:

... 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...?

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

jezule said:

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.

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