"John R. Strohm" <strohm@airmail.net> wrote in message
news:bsbpfs$j90@library2.airnews.net...
> "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*.
>

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.

Ville Voipio wrote:
> 
... snip ...
> 
> 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).

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.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Ville Voipio wrote:

> Mark Borgerson <m-a-r-k@oes.to> writes:
> 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.

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

> 
> 
>>Do most of the DSPs now come with built-in flash and a JTAG port?
> 
> 
> No. (But neither has most AVRs a JTAG port.) There are some DSP/uC
> combos which offer these. However, using DSPs is usually clumsier
> than using small uCs. And usually you need to use rather expensive 
> proprietary tools. In large-scale production using clumsy processors
> and expensive tools may not be a problem if the unit cost gets
> lower.

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

mojaveg@iwvisp.com (Everett M. Greene) writes:

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

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.

> I don't see a correlation between precision of time values and
> computational speed or load.

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)

In article <20031227.7D75058.99F1@mojaveg.iwvisp.com>, 
mojaveg@iwvisp.com says...
> Ville Voipio <vvoipio@kosh.hut.fi> writes:
> > Mark Borgerson <m-a-r-k@oes.to> writes:
> > 
> > > 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.
> > 
> > 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.
> 
> 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.
> 
> > > 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.
> > 
> > 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.
> 
> 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.


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


> 

In article <i3kbrpuu239.fsf@kosh.hut.fi>, vvoipio@kosh.hut.fi says...
> Mark Borgerson <m-a-r-k@oes.to> writes:
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.

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.
> 
> ---
> 
> > A key factor is whether the standard C math libraries take advantage
> > of the hardware multiply.
> 
> True. IMHO, all decent libraries should use the hw wherever possible.
> With AVR/MSP430/ARM/several others the comparison can be made by using
> gcc. I'd guess the differences between gcc and commercial compilers
> in maths are rather small.
> 
> ---
> 
> > Do most of the DSPs now come with built-in flash and a JTAG port?
> 
> No. (But neither has most AVRs a JTAG port.) There are some DSP/uC
> combos which offer these. However, using DSPs is usually clumsier
> than using small uCs. And usually you need to use rather expensive 
> proprietary tools. In large-scale production using clumsy processors
> and expensive tools may not be a problem if the unit cost gets
> lower.

True.  I feel lucky to be working in the small volume,  high value-added
part of the market.
> 
> > For
> > small-volume products, the system complexity and ease of programming
> > are important issues.
> 
> I agree.
> 
Mark Borgerson

Ville Voipio <vvoipio@kosh.hut.fi> writes:
> Mark Borgerson <m-a-r-k@oes.to> writes:
> 
> > 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.
> 
> 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.

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.

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

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.

Mark Borgerson <m-a-r-k@oes.to> writes:

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

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.

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

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.

True. IMHO, all decent libraries should use the hw wherever possible.
With AVR/MSP430/ARM/several others the comparison can be made by using
gcc. I'd guess the differences between gcc and commercial compilers
in maths are rather small.

---

> Do most of the DSPs now come with built-in flash and a JTAG port?

No. (But neither has most AVRs a JTAG port.) There are some DSP/uC
combos which offer these. However, using DSPs is usually clumsier
than using small uCs. And usually you need to use rather expensive 
proprietary tools. In large-scale production using clumsy processors
and expensive tools may not be a problem if the unit cost gets
lower.

> For
> small-volume products, the system complexity and ease of programming
> are important issues.

I agree.

- 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

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