EmbeddedRelated.com
Forums

MSP430 GCC floating point libray for smaller code ?

Started by r_bo...@yahoo.com October 17, 2013
Hello,

I have to modify code for an existing board with a 8 K MSP430 Series 1device. I'm
using MSPGCC and Eclipse.

The "old" code just fits 8K. The new code doesn't, even with -os option. I assume the
FP library consumes most of the memory space.

Does anybody know if there is an other FP library for MSPGCC which delivers
smaller code for Series 1 MSP430 devices ?

Thank you.

Regards

Robert

Beginning Microcontrollers with the MSP430

TI had FP-assembler routines for the MSP (maybe still downloadable?), however
you can not use it like "a*b", you need to do a call it mul(a,b).

But - are you sure your problem is FP? Maybe it's printf. (take a look in the
map-file, which functions are the biggest ones)

Matthias

:

> Hello,
>
> I have to modify code for an existing board with a 8 K MSP430 Series
> 1device. I'm
> using MSPGCC and Eclipse.
>
> The "old" code just fits 8K. The new code doesn't, even with -os
> option. I assume the FP library consumes most of the memory space.
>
> Does anybody know if there is an other FP library for MSPGCC which
> delivers smaller code for Series 1 MSP430 devices ?
>
> Thank you.
>
> Regards
>
> Robert

On 17/10/13 12:54, r...@yahoo.com wrote:
> Hello,
>
> I have to modify code for an existing board with a 8 K MSP430 Series
> 1device. I'm using MSPGCC and Eclipse.
>
> The "old" code just fits 8K. The new code doesn't, even with -os
> option. I assume the FP library consumes most of the memory space.

Don't assume - check. Look through the map file to see what is taking
space.

>
> Does anybody know if there is an other FP library for MSPGCC which
> delivers smaller code for Series 1 MSP430 devices ?

Floating point routines are only linked in if you use them (or use
another function that uses them - printf is a common case). Are you
actually /using/ floating point? Do you really need it? It is rare
that floating point is the most efficient way to handle calculations on
a small microcontroller (though it is sometimes the easiest).

And if the root cause is printf (or related functions), then consider
replacing them. Printf and friends are very inefficient in most cases -
the code is big and slow.

>
> Thank you.
>
> Regards
>
> Robert
>
On 10/17/2013 06:39 AM, David Brown wrote:
> Floating point routines are only linked in if you use them (or use
> another function that uses them - printf is a common case). Are you
> actually /using/ floating point? Do you really need it? It is rare
> that floating point is the most efficient way to handle calculations on
> a small microcontroller (though it is sometimes the easiest).
>
> And if the root cause is printf (or related functions), then consider
> replacing them. Printf and friends are very inefficient in most cases -
> the code is big and slow.

My current project is suffering from code bloat so this topic strikes a
nerve.

Using uprintf added a modest amount of code but what really pushed it up
was the use of floating point. It increased the code so much that I had
to think about what to do:

1) Write replacement fixed point code. I don't need the dynamic range of
floating point so fixed point would work fine. Replacing the
multiplications and such would be tedious but doable. What would really
take some time is replacements for sqrt, atan2, sin, and cos. I wrote a
CORDIC atan2 once but that was on a PIC and I have forgotten how to do
that since.

2) Move to a part with more memory. Moving from a 32K MSP430G2744 to a
56K MSP430G2955 which cost a few dimes more made this an easy choice.
--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving

On 18/10/13 01:23, David W. Schultz wrote:
> On 10/17/2013 06:39 AM, David Brown wrote:
> > Floating point routines are only linked in if you use them (or use
> > another function that uses them - printf is a common case). Are you
> > actually /using/ floating point? Do you really need it? It is rare
> > that floating point is the most efficient way to handle calculations on
> > a small microcontroller (though it is sometimes the easiest).
> >
> > And if the root cause is printf (or related functions), then consider
> > replacing them. Printf and friends are very inefficient in most cases -
> > the code is big and slow.
>
> My current project is suffering from code bloat so this topic strikes a
> nerve.
>
> Using uprintf added a modest amount of code but what really pushed it up
> was the use of floating point. It increased the code so much that I had
> to think about what to do:
>

Usually in embedded systems, printf and friends can be easily replaced
with dedicated functions for printing out strings and integers, taking
up much less space and running much faster - as well as being easier to
check for correctness at compile-time (though gcc can do type-checking
on printf parameters).

> 1) Write replacement fixed point code. I don't need the dynamic range of
> floating point so fixed point would work fine. Replacing the
> multiplications and such would be tedious but doable. What would really
> take some time is replacements for sqrt, atan2, sin, and cos. I wrote a
> CORDIC atan2 once but that was on a PIC and I have forgotten how to do
> that since.

Depending on the accuracy you need, these sorts of functions can be
written quite small and fast - a simple cubic approximation for a
quarter-cycle is often good enough for sin and cos. Speed is not always
important, but such dedicated functions can easily be hundreds of times
faster than generic maths library functions.

>
> 2) Move to a part with more memory. Moving from a 32K MSP430G2744 to a
> 56K MSP430G2955 which cost a few dimes more made this an easy choice.
>

This is, of course, the easiest fix!

T

Thank you all for all the hints, I appreciate it..

Moving to a part with more memory would be the best solution indeed , but in this
particular case it is not possible. The PCB exists and must be used also for this project.

The project belongs to a kind of sensor conditioner. There are no printf and similar function calls

at all . Just some 100 byte more would clear the situation.

Anyway, I'm going to try fix point arithmetic and I found some code which works with Look-up tables.
Maybe it can be modified for my requirements.

Thanks a lot again

Robert

---In m..., wrote:

On 18/10/13 01:23, David W. Schultz wrote:
> On 10/17/2013 06:39 AM, David Brown wrote:
> > Floating point routines are only linked in if you use them (or use
> > another function that uses them - printf is a common case). Are you
> > actually /using/ floating point? Do you really need it? It is rare
> > that floating point is the most efficient way to handle calculations on
> > a small microcontroller (though it is sometimes the easiest).
> >
> > And if the root cause is printf (or related functions), then consider
> > replacing them. Printf and friends are very inefficient in most cases -
> > the code is big and slow.
>
> My current project is suffering from code bloat so this topic strikes a
> nerve.
>
> Using uprintf added a modest amount of code but what really pushed it up
> was the use of floating point. It increased the code so much that I had
> to think about what to do:
>

Usually in embedded systems, printf and friends can be easily replaced
with dedicated functions for printing out strings and integers, taking
up much less space and running much faster - as well as being easier to
check for correctness at compile-time (though gcc can do type-checking
on printf parameters).

> 1) Write replacement fixed point code. I don't need the dynamic range of
> floating point so fixed point would work fine. Replacing the
> multiplications and such would be tedious but doable. What would really
> take some time is replacements for sqrt, atan2, sin, and cos. I wrote a
> CORDIC atan2 once but that was on a PIC and I have forgotten how to do
> that since.

Depending on the accuracy you need, these sorts of functions can be
written quite small and fast - a simple cubic approximation for a
quarter-cycle is often good enough for sin and cos. Speed is not always
important, but such dedicated functions can easily be hundreds of times
faster than generic maths library functions.

>
> 2) Move to a part with more memory. Moving from a 32K MSP430G2744 to a
> 56K MSP430G2955 which cost a few dimes more made this an easy choice.
>

This is, of course, the easiest fix!
If you only need 100bytes try using the INFO memory as code space if not
already used, else pick your routines apart and hand optimise the code,
reduce any tables with nulls or long repetitive strings

Al

On 18/10/2013 3:52 PM, b...@gmx.de wrote:
> T
>
> Thank you all for all the hints, I appreciate it..
> Moving to a part with more memory would be the best solution indeed ,
> but in this
>
> particular case it is not possible. The PCB exists and must be used
> also for this project.
> The project belongs to a kind of sensor conditioner. There are no
> printf and similar function calls
>
> at all . Just some 100 byte more would clear the situation.
> Anyway, I'm going to try fix point arithmetic and I found some code
> which works with Look-up tables.
> Maybe it can be modified for my requirements.
>
> Thanks a lot again
>
> Robert
> ---In m..., wrote:
>
> On 18/10/13 01:23, David W. Schultz wrote:
>
> > On 10/17/2013 06:39 AM, David Brown wrote:
> > > Floating point routines are only linked in if you use them (or use
> > > another function that uses them - printf is a common case).
> Are you
> > > actually /using/ floating point? Do you really need it? It is rare
> > > that floating point is the most efficient way to handle
> calculations on
> > > a small microcontroller (though it is sometimes the easiest).
> > >
> > > And if the root cause is printf (or related functions), then
> consider
> > > replacing them. Printf and friends are very inefficient in
> most cases -
> > > the code is big and slow.
> >
> > My current project is suffering from code bloat so this topic
> strikes a
> > nerve.
> >
> > Using uprintf added a modest amount of code but what really
> pushed it up
> > was the use of floating point. It increased the code so much
> that I had
> > to think about what to do:
> > Usually in embedded systems, printf and friends can be easily replaced
> with dedicated functions for printing out strings and integers, taking
> up much less space and running much faster - as well as being easier to
> check for correctness at compile-time (though gcc can do type-checking
> on printf parameters).
>
> > 1) Write replacement fixed point code. I don't need the dynamic
> range of
> > floating point so fixed point would work fine. Replacing the
> > multiplications and such would be tedious but doable. What would
> really
> > take some time is replacements for sqrt, atan2, sin, and cos. I
> wrote a
> > CORDIC atan2 once but that was on a PIC and I have forgotten how
> to do
> > that since.
>
> Depending on the accuracy you need, these sorts of functions can be
> written quite small and fast - a simple cubic approximation for a
> quarter-cycle is often good enough for sin and cos. Speed is not always
> important, but such dedicated functions can easily be hundreds of times
> faster than generic maths library functions.
>
> >
> > 2) Move to a part with more memory. Moving from a 32K
> MSP430G2744 to a
> > 56K MSP430G2955 which cost a few dimes more made this an easy
> choice.
> > This is, of course, the easiest fix!
>
For the 430 my favorite compiler has always been crossworks... In my experience it has ALWAYS generated code considerably smaller than any of the competition. I remember one project that I had to modify for someone.. It barely fit as it was and then needed additionaly functionality, moved it over to crossworks and it was like I moved it to a larger processor.. The code was more compact and faster to boot... Thanks Paul!

---In m..., wrote:

Hello,

I have to modify code for an existing board with a 8 K MSP430 Series 1device. I'm
using MSPGCC and Eclipse.

The "old" code just fits 8K. The new code doesn't, even with -os option. I assume the
FP library consumes most of the memory space.

Does anybody know if there is an other FP library for MSPGCC which delivers
smaller code for Series 1 MSP430 devices ?

Thank you.

Regards

Robert
…unfortunately, the CrossWorks MSP430 product is entering its twilight years. There is nowhere to go with it, the market is skewed, and TI are taking a direction that doesn’t foster independents.

Quadravox have dropped out. ImageCraft have dropped out. And, unfortunately, I think we need to bow out, leaving IAR and CCS as the options for MSP430 development, with Red Hat and GCC moving to fulfil anything else.

Regards,

--

Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk

SolderCore Development Platform http://www.soldercore.com

From: m... [mailto:m...] On Behalf Of j...@yahoo.com
Sent: 08 November 2013 03:56
To: m...
Subject: [msp430] RE: MSP430 GCC floating point libray for smaller code ?

For the 430 my favorite compiler has always been crossworks... In my experience it has ALWAYS generated code considerably smaller than any of the competition. I remember one project that I had to modify for someone.. It barely fit as it was and then needed additionaly functionality, moved it over to crossworks and it was like I moved it to a larger processor.. The code was more compact and faster to boot... Thanks Paul!

---In m..., wrote:

Hello,

I have to modify code for an existing board with a 8 K MSP430 Series 1device. I'm
using MSPGCC and Eclipse.

The "old" code just fits 8K. The new code doesn't, even with -os option. I assume the
FP library consumes most of the memory space.

Does anybody know if there is an other FP library for MSPGCC which delivers
smaller code for Series 1 MSP430 devices ?

Thank you.

Regards

Robert
I am so sorry to hear that.. It is a great product.. I'll use it as long as I can...  I'll probably stay with supported processors as long as I can rather than move onto newer processors once support ends...
Maybe I'll even move onto another processor that you support.... Any discounts for existing customers moving on?
 
 

On Friday, November 8, 2013 3:56 AM, Paul Curtis wrote:

 
>…unfortunately, the CrossWorks MSP430 product is entering its twilight years.  There is nowhere to go with it, the market is skewed, and TI are taking a direction that doesn’t foster independents.

>Quadravox have dropped out.  ImageCraft have dropped out.  And, unfortunately, I think we need to bow out, leaving IAR and CCS as the options for MSP430 development, with Red Hat and GCC moving to fulfil anything else.

>Regards,

>--
>Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk/
>SolderCore Development Platform      http://www.soldercore.com/



>From:m... [mailto:m...] On Behalf Of j...@yahoo.com
>Sent: 08 November 2013 03:56
>To: m...
>Subject: [msp430] RE: MSP430 GCC floating point libray for smaller code ?

>For the 430 my favorite compiler has always been crossworks... In my experience it has ALWAYS generated code considerably smaller than any of the competition.  I remember one project that I had to modify for someone.. It barely fit as it was and then needed additionaly functionality, moved it over to crossworks and it was like I moved it to a larger processor.. The code was more compact and faster to boot... Thanks Paul!
>---In m..., wrote:
>Hello,
>
>I have to modify code for an existing board with a 8 K MSP430 Series 1device. I'm
>using MSPGCC and Eclipse.
>
>The "old" code just fits 8K. The new code doesn't, even with -os option. I assume the
>FP library consumes most of the memory space.
>
>Does anybody know if there is an other FP library for MSPGCC which delivers
>smaller code for Series 1 MSP430 devices ?
>
>Thank you.
>
>Regards
>
>Robert
>
>
>