Computational power AVR vs. MSP430?

Does anyone have any idea how AVR and MSP430 compare in terms of floating
point and integer math? We need to do some computational number crunching
(preprocessing) in our devices but aren't sure which of the above to pick.

The MSP430 is 16 bits so it should be faster in math it seems to me, but are
there other aspects which are important? The computations are 'DSP like'
(lots of adding amd multiplication).

"Dr. O" <dr.o@xxxxx> wrote in message
news:3fe952f1$0$64979$1b62eedf@news.euronet.nl...
> Does anyone have any idea how AVR and MSP430 compare in terms of floating
> point and integer math? We need to do some computational number crunching
> (preprocessing) in our devices but aren't sure which of the above to pick.
>
> The MSP430 is 16 bits so it should be faster in math it seems to me, but are
> there other aspects which are important? The computations are 'DSP like'
> (lots of adding amd multiplication).

The first thing you have to quantify is HOW MUCH adding and multiplication you
have to do.

How wide are the operands?  How many per second do you have to process?

If you are doing multiply-and-accumulate kinds of things at DSP rates, you
probably need a real DSP.

My understanding is that neither AVR nor MSP430 have hardware floating point,
which means that floating point operations will be *S*L*O*W*.

In article <bsbpfs$j90@library2.airnews.net>, strohm@airmail.net says...
> "Dr. O" <dr.o@xxxxx> wrote in message
> news:3fe952f1$0$64979$1b62eedf@news.euronet.nl...
> > Does anyone have any idea how AVR and MSP430 compare in terms of floating
> > point and integer math? We need to do some computational number crunching
> > (preprocessing) in our devices but aren't sure which of the above to pick.
> >
> > The MSP430 is 16 bits so it should be faster in math it seems to me, but are
> > there other aspects which are important? The computations are 'DSP like'
> > (lots of adding amd multiplication).
> 
> The first thing you have to quantify is HOW MUCH adding and multiplication you
> have to do.
> 
> How wide are the operands?  How many per second do you have to process?
> 
> If you are doing multiply-and-accumulate kinds of things at DSP rates, you
> probably need a real DSP.
> 
> My understanding is that neither AVR nor MSP430 have hardware floating point,
> which means that floating point operations will be *S*L*O*W*.

Also, some, but not all, members of the MSP430 family have a hardware
multiplier.

--Gene

Think fixed point math rather than floating point. It is MUCH more
efficient.


"Dr. O" <dr.o@xxxxx> wrote in message
news:3fe952f1$0$64979$1b62eedf@news.euronet.nl...
> Does anyone have any idea how AVR and MSP430 compare in terms of floating
> point and integer math? We need to do some computational number crunching
> (preprocessing) in our devices but aren't sure which of the above to pick.
>
> The MSP430 is 16 bits so it should be faster in math it seems to me, but
are
> there other aspects which are important? The computations are 'DSP like'
> (lots of adding amd multiplication).
>
>

"Thomas W. Carley" <tcarley@eng.umd.edu> wrote in message
news:99ednci7uYkpAnSiRVn-hw@comcast.com...
> Think fixed point math rather than floating point. It is MUCH more
> efficient.

It isn't that simple.  Doing fixed point math, you have to worry a lot more
about scale factors and where your binary point is at any given instant.  You
MAY have to worry about which way an operation will truncate.

> "Dr. O" <dr.o@xxxxx> wrote in message
> news:3fe952f1$0$64979$1b62eedf@news.euronet.nl...
> > Does anyone have any idea how AVR and MSP430 compare in terms of floating
> > point and integer math? We need to do some computational number crunching
> > (preprocessing) in our devices but aren't sure which of the above to pick.
> >
> > The MSP430 is 16 bits so it should be faster in math it seems to me, but
> are
> > there other aspects which are important? The computations are 'DSP like'
> > (lots of adding amd multiplication).
> >
> >
>
>

John R. Strohm said...
> "Thomas W. Carley" <tcarley@eng.umd.edu> wrote in message
> > 
> > Think fixed point math rather than floating point. It is MUCH more
> > efficient.
> 
> It isn't that simple.  Doing fixed point math, you have to worry a lot more
> about scale factors and where your binary point is at any given instant.  You
> MAY have to worry about which way an operation will truncate.

True... but we get paid to worry about such things.


Casey

"Casey" <cclremovethispart@cox.net> wrote in message
news:YXjGb.10436$JD6.364@lakeread04...
> John R. Strohm said...
> > "Thomas W. Carley" <tcarley@eng.umd.edu> wrote in message
> > >
> > > Think fixed point math rather than floating point. It is MUCH more
> > > efficient.
> >
> > It isn't that simple.  Doing fixed point math, you have to worry a lot more
> > about scale factors and where your binary point is at any given instant.
You
> > MAY have to worry about which way an operation will truncate.
>
> True... but we get paid to worry about such things.

Not enough.

The MSP430F149 and other members of the family have a built in hardware 
multiplier that handles MAC and MACS.Try to avoid floating point in any 
small micro. I've never found a situation yet where I couldn't use fixed 
point, which gives better accuracy than floating point. Even in mil spec 
navigation systems.

Al

Dr. O wrote:

> Does anyone have any idea how AVR and MSP430 compare in terms of floating
> point and integer math? We need to do some computational number crunching
> (preprocessing) in our devices but aren't sure which of the above to pick.
> 
> The MSP430 is 16 bits so it should be faster in math it seems to me, but are
> there other aspects which are important? The computations are 'DSP like'
> (lots of adding amd multiplication).
> 
> 

"John R. Strohm" <strohm@airmail.net> writes:

> It isn't that simple.  Doing fixed point math, you have to worry a lot more
> about scale factors and where your binary point is at any given instant.  You
> MAY have to worry about which way an operation will truncate.

That is true. On the other hand, it does not hurt knowing what really
happens during the calculations. Real-world data very seldom has more
than 16 significant bits, and the dynamic range is also rather limited,
so 16 bits of fixed point is usually enough. But, again, there are
applications where this is not true.

Neither of the two little chips is a real DSP. At the same clock AVR is
faster in bit-banging, as it consumes fewer clocks per instruction.
However, in maths MSP430 may be faster, as it has a 16x16 multiplication
(vs. AVR's 8x8). And then, is the most important facter the same clock 
frequency, power consumption, or dollarage?

If the device is spending over 90% of its time crunching numbers, then
you might just write the core code for both and count the clocks.
If you are using C this should be quite quick.

Even if the price is the limiting factor, you might still consider using 
a DSP. They are not that expensive compared to AVR/MSP430 with HW 
multiplications. Even the power consumption should be reasonable at 
a low clock frequency (yes, you can run a 100 MHz device at 2 MHz, 
and get a low power consumption). Many ARM cores have a MAC instruction, 
and the power consumption is rather reasonable. There are also some 
DSP/uC combinations, such as TI C2000-series, which might be interesting.

- Ville

-- 
Ville Voipio, Dr.Tech., M.Sc. (EE)

In article <i3kisk4kkfs.fsf@kosh.hut.fi>, vvoipio@kosh.hut.fi says...
> "John R. Strohm" <strohm@airmail.net> writes:
> 
> > It isn't that simple.  Doing fixed point math, you have to worry a lot more
> > about scale factors and where your binary point is at any given instant.  You
> > MAY have to worry about which way an operation will truncate.
> 
> That is true. On the other hand, it does not hurt knowing what really
> happens during the calculations. Real-world data very seldom has more
> than 16 significant bits, and the dynamic range is also rather limited,
> so 16 bits of fixed point is usually enough. But, again, there are
> applications where this is not true.

The application where I found that to be untrue most recently was
GPS navigation.  The  GPS delivered Earth-centered, Earth-Fixed   data 
in meters that required about 24 bits and had a noise level of about 2 
to 3 bits.

Converting the ECEF to Latitude and longitude was certainly easier
in floating point, and was not too great a processing burden as
I only received data once per second.  I did manage to optimize the
code by pre-computing some relevant sines and cosines.
> 
> Neither of the two little chips is a real DSP. At the same clock AVR is
> faster in bit-banging, as it consumes fewer clocks per instruction.
> However, in maths MSP430 may be faster, as it has a 16x16 multiplication
> (vs. AVR's 8x8). And then, is the most important facter the same clock 
> frequency, power consumption, or dollarage?

A key factor is whether the standard C math libraries take advantage
of the hardware multiply.
> 
> If the device is spending over 90% of its time crunching numbers, then
> you might just write the core code for both and count the clocks.
> If you are using C this should be quite quick.
> 
> Even if the price is the limiting factor, you might still consider using 
> a DSP. They are not that expensive compared to AVR/MSP430 with HW 
> multiplications. Even the power consumption should be reasonable at 
> a low clock frequency (yes, you can run a 100 MHz device at 2 MHz, 
> and get a low power consumption). Many ARM cores have a MAC instruction, 
> and the power consumption is rather reasonable. There are also some 
> DSP/uC combinations, such as TI C2000-series, which might be interesting.
> 

Do most of the DSPs now come with built-in flash and a JTAG port?  For
small-volume products, the system complexity and ease of programming
are important issues.
> - Ville
> 
> 
Mark Borgerson