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

Reply to
Dr. O
Loading thread data ...

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

Reply to
John R. Strohm

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

--Gene

Reply to
Gene S. Berkowitz

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

are

Reply to
Thomas W. Carley

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.

Reply to
John R. Strohm

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

Casey

Reply to
Casey

You

Not enough.

Reply to
John R. Strohm

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:

Reply to
onestone

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)
Reply to
Ville Voipio

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.

A key factor is whether the standard C math libraries take advantage of the hardware multiply.

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.

Mark Borgerson

Reply to
Mark Borgerson

Time-based calculations are really an exception. It is very easy to measure time to more than 16 bits. With GPS the absolute accuracy is extremely high as the time sources are locked to the standard time.

And this is also a property of time measurements; if you have very large dynamic range, you are not in a hurry. Of course, this is an over- simplification, but still this seems to apply to time-based measurements in general.

--
> A key factor is whether the standard C math libraries take advantage
> of the hardware multiply.
 Click to see the full signature
Reply to
Ville Voipio

It's not only the time values -- the range values are quite large when measured in meters (>2e6). The mathematics of satellite navigation are not the best conditioned and can get very tricky to avoid loss of accuracy.

I don't see a correlation between precision of time values and computational speed or load. Most time processing consists of computing the difference between "now" and some previous time which probably isn't that far in the past. Even using the VAX/VMS microseconds since some date long ago time format ain't no big deal computationally.

Reply to
Everett M. Greene

That's right. Time measurements are an area where 32-bit numbers are often required. If you stay in seconds, it's not too bad and there isn't much call for multiply and divide. However, as soon as you decide to change the Unix seconds to time and date, watch out!

Even more complex is the coordination of GPS time (week number and seconds into the week) with UNIX time. Every time I print a date and time with some GPS data, I swear that I'm going to write a routine that operates on an initial time and date string and simply increments the second, checks for > 9, if needed increments the tens of seconds, etc... Of course, I've not yet gotten around to writing that routine. ;-)

Of course, the routine would have much longer run time at 23:59:59, but the run time is quite variable on routines that divide without hardware assist in any case.

True. I feel lucky to be working in the small volume, high value-added part of the market.

Mark Borgerson

Reply to
Mark Borgerson

That's all very true until you want to convert those seconds and microseconds into "21:30:44.20 12/18/2003" when possible I try to have that conversion done on the PC displaying the data, rather than on the 16-bit, 8MHz processor in the data acquisition system.

Mark Borgerson

>
Reply to
Mark Borgerson

But still the range values are calculated from time measurements. As far as I can see, time (frequency, etc.) is the only property you can measure with such a large dynamic range with the same device. Most readers of this NG can make a simple device which can measure time in microseconds and years with the same hardware and software. As one year is around 32 000 000 000 000 us, this gives a very large dynamic range (45 bits).

Even the accuracy in time measurements is around 10^-13, IIRC. So, both the dynamic range and the accuracy are far better than with voltage, current, angle, distance, etc. (If current could be measured electron-by-electron it would share the same properties.)

So, the mesurement in satellite navigation is a time measurement and thus the dynamic range is very large and a lot of numbers is required.

Not computational speed, but measurement speed. With almost any measurement you will gain more dynamic range by waiting longer. Going back to the time measurement: if your measurement time is in microseconds, you get less dynamic range than if you measure years.

The same applies to many other measurements, as well. If you need to measure a DC voltage, you're better off using a slow converter. If you need to dig a faint signal from noise, you'll have to average it for a longer time (regardless of modulation scheme used).

- Ville

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

I still do all my navigational computation on the MSP430, its far faster than floating point.

Actually most of the popular ones now do. A really good value part at the moment is the 56F800 from Motorola, Small part, small price, JTAG and a $30 dev kit.

Al

Reply to
onestone

... snip ...

In fact the best accuracy per monetary unit conversions are done by converting to time in the first place. Two examples are the (very cheap) dual slope converters in multi-meters, and the (not so cheap) linear rundown converters in nuclear radiation analysers. The latter also satisfy stringent differential linearity requirements.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

floating

crunching

pick.

are

you

point,

The original AVRs do not have hardware multipliers, but the Mega ones do. The mps430f13x family does not have hardware multipliers, but the msp430f14x family does.

If you are looking to do heavy maths with these chips, however, it is important to know exactly what you are looking for and try to find short-cuts. For example, if you are only going to be working with a number of fixed constants, you could be faster with look-up tables (the mega128 has a fair amount of flash space for tables). For floating point, think about the accuracy you need.

In general, however, the msp430 is likely to have the edge by being 16-bit, even though the avr has a faster clock and instruction-per-clock rate.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.