Help to optimize

[sucotronic 6]

I'm building a small project with a msp430G2231 and a pressure sensor (bmp085) connected through i2c. I'm also using a snippet of code to output code through serial port.

My problem is that the code compiled exceeds the flash size of the uc, but I'm sure there are things that can be optimized. So I'm asking to more expert people about how to optimize it.

Thanks in advance

i2c.zip

[sucotronic 6]

Doing some changes in the code I've arrived to the conclusion that when compiling the following code:

p = b7 < 0x80000000 ? (b7 * 2) / b4 : (b7 / b4) * 2;

mspgcc need almost 500 bytes to do the operation. Is this normal?

[bluehash 1,581]

That results in a lot of generated intermediate code.

Try breaking it up, us an if statement for the comparison.

 

If you have to multiply x by 2, right shifting by 1 might be faster.

y= x

[nobody 47]

Just one quick question:

 

You turn on optimization in mspgcc?

 

Tip can be found on this page: http://mspgcc.sourceforge.net/manual/c1509.html

 

... And one little hint: Try to change your code. Do not use LONG variables. Use only "natural" type of variables. For MSP430 natural types are INT, UNSIGNED, CHAR. Each non-natural type variable add additional libraries to your code.

[sucotronic 6]

Just one quick question:

 

You turn on optimization in mspgcc?

 

Tip can be found on this page: http://mspgcc.sourceforge.net/manual/c1509.html

 

... And one little hint: Try to change your code. Do not use LONG variables. Use only "natural" type of variables. For MSP430 natural types are INT, UNSIGNED, CHAR. Each non-natural type variable add additional libraries to your code.

 

I actually use the following command to compile:

msp430-gcc -Os -mmcu=msp430x2231 -o i2c.elf i2c.c

Using the option -O2 produces larger code, so is better to use -Os.

I need to use long variables, because it's specified in the bosch sensor documentation, but perhaps there is a way to do some kind of conversion. Thanks for suggestion.

[zeke 693]

What pressure sensor are you using here?

 

That's one heck of an algorithm to compute the pressure:

//calculate the pressure
  b6 = b5 - 4000;
  x1 = (b2 * (b6 * b6 >> 12)) >> 11; 
  x2 = ac2 * b6 >> 11;
  x3 = x1 + x2;
  b3 = (((int32_t) ac1 * 4 + x3)<<1 + 2) >> 2;
  x1 = ac3 * b6 >> 13;
  x2 = (b1 * (b6 * b6 >> 12)) >> 16;
  x3 = ((x1 + x2) + 2) >> 2;
  b4 = (ac4 * (uint32_t) (x3 + 32768)) >> 15;
  b7 = ((uint32_t) up - b3) * (50000 >> 1);
  p = b7 < 0x80000000 ? (b7 * 2) / b4 : (b7 / b4) * 2;

  x1 = (p >> 8) * (p >> 8);
  x1 = (x1 * 3038) >> 16;
  x2 = (-7357 * p) >> 16;
  press = p + ((x1 + x2 + 3791) >> 4);

 

In my humble opinion, it would seem a lot easier to use a pressure transducer like a MPX5100AP attached to an A/D input. Just read that one input, apply a correction factor and Bob's your uncle.

 

It would save a heck of a lot of code space too.

 

What am I missing?

 

Oh, right. I optimized your hardware. You asked for software optimization.

 

Sorry about that. :oops:

[GeekDoc 226]

In my humble opinion, it would seem a lot easier to use a pressure transducer like a MPX5100AP attached to an A/D input. Just read that one input, apply a correction factor and Bob's your uncle.

+1 for using "Bob's your uncle." I love that saying, but don't get to use it much.

 

BTW: @sucotronic: The saying translates to, "the rest is obvious."

[zeke 693]

Okay. My eyes must be going bad because I just noticed that you indicated exactly which sensor you are using - the BMP085. :oops:

 

Now that I look at it, I can see its appeal. Pressure and temperature in one sensor and it's tiny. Cool.

 

I have read the datasheet and this is the method that Bosch uses to perform the calculation:

 

if ( b7 < 0x80000000 )
  {
 p = (b7 << 1) / b4;
  }
  else
  {
 p = (b7 / b4) << 1);
  }

 

whereas you did it this way:

p = b7 < 0x80000000 ? (b7 * 2) / b4 : (b7 / b4) * 2;

 

Why not give the first method a try? The compiler may be able to optimize it better. Yes, I'm grasping at straws when I say this.

 

Oh, you could try this method to try to get the compiler to optimize it better:

 

if ( b7 < 0x80000000 )
 {
   p = (b7 << 1) / b4;
 }
 else
 {
   p = ( (b7 << 1) / (b4 << 1) );
 }

 

How does that work for you?

 

If not then you might have to learn how to do the calculations in assembly to squeeze every last drop of computational power out of the msp.

 

If it that doesn't help then I would make a guess and say that 32 bit math is not the MSP430G2231's strong suit.

[sucotronic 6]

In my humble opinion, it would seem a lot easier to use a pressure transducer like a MPX5100AP attached to an A/D input. Just read that one input, apply a correction factor and Bob's your uncle.

+1 for using "Bob's your uncle." I love that saying, but don't get to use it much.

 

BTW: @sucotronic: The saying translates to, "the rest is obvious."

 

The main reason to not use the MPX5100AP is easy to understand...it costs the double than the Bosch one! 14$

And the problem with the math is the use of long variables that produces a lot of compiled code. I'm going to wait until TI start sending the new value line chips (but also at the same time will try the pic16f1828, similar price and better characteristics.

[sucotronic 6]

Okay. My eyes must be going bad because I just noticed that you indicated exactly which sensor you are using - the BMP085. :oops:

 

Now that I look at it, I can see its appeal. Pressure and temperature in one sensor and it's tiny. Cool.

 

I have read the datasheet and this is the method that Bosch uses to perform the calculation:

 

if ( b7 < 0x80000000 )
  {
 p = (b7 << 1) / b4;
  }
  else
  {
 p = (b7 / b4) << 1);
  }

 

whereas you did it this way:

p = b7 < 0x80000000 ? (b7 * 2) / b4 : (b7 / b4) * 2;

 

Why not give the first method a try? The compiler may be able to optimize it better. Yes, I'm grasping at straws when I say this.

 

Oh, you could try this method to try to get the compiler to optimize it better:

 

if ( b7 < 0x80000000 )
 {
   p = (b7 << 1) / b4;
 }
 else
 {
   p = ( (b7 << 1) / (b4 << 1) );
 }

 

How does that work for you?

 

If not then you might have to learn how to do the calculations in assembly to squeeze every last drop of computational power out of the msp.

 

If it that doesn't help then I would make a guess and say that 32 bit math is not the MSP430G2231's strong suit.

 

All the code combinations produce the same quantity of overflowed compiled code

[cde 334]

Just a quick observation. You are using 32bit ints. MSP430 is 16bit int oriented. That could be causing the overflow. Any way you can change the math around a bit (pun not intended) to adjust for that?

 

Another, not so optimal (Again, pni) option is to delegate a second msp as a math processor. Program it with the i2c slave example from TI, get the data from the sensor, throw it at the second msp, and read back the processed answer. Since it's i2c, no extra pins used. Atleast until the newer chips ship/are available.

[sucotronic 6]

Just a quick observation. You are using 32bit ints. MSP430 is 16bit int oriented. That could be causing the overflow. Any way you can change the math around a bit (pun not intended) to adjust for that?

 

Another, not so optimal (Again, pni) option is to delegate a second msp as a math processor. Program it with the i2c slave example from TI, get the data from the sensor, throw it at the second msp, and read back the processed answer. Since it's i2c, no extra pins used. Atleast until the newer chips ship/are available.

 

Of course, it is also a valid solution, but my main goal is to keep the project simple, and putting another mcu only will serve to consume more power and space in the pcb.

Just today I've received a mail from TI saying that the new msp430g chips with 4kb will be shippeg to me 22th of february, so in two week perhaps I can resume the project

[cde 334]

Space, yes (Maybe, you could always double up the msp430, like a doubledecker). Power, well, it's a msp430 afterall

 

I checked my status on TI (So complicated to find) and I have the same. Feb 22 for the dip chips (already have 2 of the soic 8kb chips )

 

Another solution you might look into is limiting the math done by making some educated assumptions about its environment. If the project will not be working in a subzero environment, no need to worry about working with negative numbers. Or by making a table of input information to corresponding real world values, you can quickly eliminate certain portions.

 

For the most part, that is how I intend to handle eclipses for a Lunar Cycle display. The math done will only calculate regular lunar cycles, which is fairly easy, and a date lookup table will be done for eclipses from today till 5 years from now, since that math is alot more intensive.

[TheDirty 33]

I converted it to CCS and best I managed to get it was 2066 bytes with full optimization and removing debug symbols. I haven't tried any actual code optimizations, yet.

 

What about using a none 430G device? One of the 4k F2xxx devices.

 

I've used the BMP085 with another processor and there is an error in the calculations from the datasheet. If you haven't already corrected for this, I can find the correction again somewhere.

[sucotronic 6]

I converted it to CCS and best I managed to get it was 2066 bytes with full optimization and removing debug symbols. I haven't tried any actual code optimizations, yet.

 

What about using a none 430G device? One of the 4k F2xxx devices.

 

I've used the BMP085 with another processor and there is an error in the calculations from the datasheet. If you haven't already corrected for this, I can find the correction again somewhere.

 

I would be great if you can pass me the correction, because I haven't foudn any errata in the Bosh website.

 

Space, yes (Maybe, you could always double up the msp430, like a doubledecker). Power, well, it's a msp430 afterall

 

I checked my status on TI (So complicated to find) and I have the same. Feb 22 for the dip chips (already have 2 of the soic 8kb chips )

 

Another solution you might look into is limiting the math done by making some educated assumptions about its environment. If the project will not be working in a subzero environment, no need to worry about working with negative numbers. Or by making a table of input information to corresponding real world values, you can quickly eliminate certain portions.

 

For the most part, that is how I intend to handle eclipses for a Lunar Cycle display. The math done will only calculate regular lunar cycles, which is fairly easy, and a date lookup table will be done for eclipses from today till 5 years from now, since that math is alot more intensive.

 

Well, to test the bmp085 sensor I've it now connected to a Ben Nanonote, and the mini linux machine is doing all the math