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

# Computational power AVR vs. MSP430?

Started by ●December 24, 2003

Reply by ●December 24, 20032003-12-24

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

Reply by ●December 24, 20032003-12-24

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

Reply by ●December 24, 20032003-12-24

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, butare> there other aspects which are important? The computations are 'DSP like' > (lots of adding amd multiplication). > >

Reply by ●December 24, 20032003-12-24

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

Reply by ●December 24, 20032003-12-24

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

Reply by ●December 24, 20032003-12-24

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

Reply by ●December 26, 20032003-12-26

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

Reply by ●December 26, 20032003-12-26

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

Reply by ●December 26, 20032003-12-26

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