arm7 atmel vs others

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
In my new arm7 design I was biased toward the atmel AT91 seriesbecause I like
the AVR chips so much, but after some research and pointers by nice foks such as
rickman and Leon, I decided to look toward other manufacturer's offerings.  One
thing I discovered is that the flash in the atmel chips (which have it) is slow!
Thus using a ball grid type package such as the AT91FR40162 with 2Meg of flash
does not give you high program execution speed.  I guess you can just run from
the 256k of on chip sram, but that should be taken into account when comparing
this chip to others.

The Phillips LPC2214 has 16k of sram and 256k of flash, but that flash is
fast...0 wait state.  The bonus features you get on this chip that do not come
on the 40008 or 40162 are dual SPI, I2C, 8 channel 10 bit ADC, 32 bit timers,
dedicated PWM, and on chip crystal oscillator with PLL.

The LPC2214 seems like a better match for my application since it eliminates my
need for an external ADC, external boot flash, external crystal, and gives me an
SPI interface to my DAC.  If the prices of the LPC21xx are any indication, it
will also cost quite a bit less than the AT91.

I could actually use a LPC210x except for the lack of an external memory bus.
If I took a simplistic but slow method of interfacing to a compact flash device
(8 bit memory mode) using general IO, I guess I could use one of these instead.
They are dirt cheap at around $5 from avnet (in stock).

Any idea of when the LPC2214 will come to full production?

Rick



Re: arm7 atmel vs others
Quoted text here. Click to load it
like
such as
One
slow!
Quoted text here. Click to load it
flash
from
comparing

The big benefits are
* small size (if you want 2 MB)
* somewhat higher speed.when executing from SRAM
   (Philips is not zero waitstate unless you are in sequential access)
    If you make dataaccesses to Flash, then this could trash the flash
access as well.
* It is much nicer to develop using SRAM than using Flash.
    It is a little bit short on peripherals though compared to the rest of
the AT91.


--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it

The AT91 has its advantages and disadvantages like all the other chips.  I am
beginning to understand that.  The 40008 is certainly the only arm7 I have found
with such large sram.

Thanks,

Rick



Re: arm7 atmel vs others
Quoted text here. Click to load it

The main problems with these chips (IMO) are:
* slow and narrow FLASH (which still uses "lots" of power)
* no caches for compensating the slow FLASH
* no MMU to protect executable code in SRAM
* the internal FLASH requires the external address/data bus, which
  greatly reduces the number of I/O pins available, even in single-chip
  applications

Philips seems to run pretty fast, thanks to the wide FLASH and the MAM
unit which acts like a small cache.  (But yes, the FLASH is smaller..)

It seems the more I learn about Atmel, Philips etc., the more I like
Motorola..  We've had a few surprises with Atmel and Philips ARM MCU's
so far (it was a mistake to expect the same level of intelligence that
has been present on Motorola chips since the Big Bang).

  -jm

Re: arm7 atmel vs others


Quoted text here. Click to load it

If you want cache, check out the OKI ML67Q500x series.  They come with
32 kB of SRAM, up to 512 kB of Flash and tons of peripherals as well as
an external bus.  Oh yes, and an 8 kB cache.  :)


Quoted text here. Click to load it

What do you mean about "intelligence"?  Are you talking about the
features on the chip or the support from the vendor?

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others
Quoted text here. Click to load it

I kinda like the physical size of the LPC210x.  :-)  But no, it doesn't
fit larger designs.  I'll check out that OKI (although I'm working on a
AT91RM9200 design right now - are there good appnotes / schematics out
there for comparison and checking our own?)

Quoted text here. Click to load it

I was talking about the peripheral features.  For example, if you put a
pin on the LPC210x in CAPture mode, it seems you can't read the pin
state any longer.  We have been using input capture on both edges and
when an edge arrives, checked the pin state - this works on Motorola
chips (HC11, HC12, MCore etc.) but not on the Philips chips.  Now that
you know it, it kinda makes sense - if a pin is connected to the CAPture
logic, it is disconnected from GPIO - but I still think it's pretty dumb.

Also, the IC pins of LPC210x seem to be in open drain mode even when
configured as MAT/CAP pins - despite of the fact that the data sheet
only mentions "open drain" for IC mode.  Of course, we didn't expect
this, so our design has no pullup on the MAT output.. nothing like this
has ever hit us with Motorola parts.

We are seeing some problems with the SPI, as well - but we don't know
what's going on for sure.  It just seems that SPI doesn't want to start
up in master mode if we want to use the SS pin as GPIO (we ran out of
pins, see ;-)

Umm.. "support from the vendor".. Is there such a thing for the Philips
chips? :-)

Anyway, I think the ARM based chips are pretty interesting in general
and as the prices drop, we can afford "real MCU's" in more and more
applications (instead of kludgy things like PICs we have been using
for a decade).

Somebody make a small chip with 256 kB or more FLASH, 64 kB SRAM,
10/100 Mbps Ethernet and some UARTs, timers etc.. :-)

  -jm


Re: arm7 atmel vs others
Quoted text here. Click to load it

Yes, the Philips LPC210x parts are very small.  But I am not sure why
you need a 32 bit processor if you only need to control some GPIO or SIO
ports.  Of course you could say, why not? with the incredibly small
price difference to an 8 bit processor.  But the Philips parts are
currently just too limited for my designs.  


Quoted text here. Click to load it

Unless you know the input does not change very fast, this could produce
errors.  But yes, I agree that it seems odd that you can't read the
pin.  I'm not sure how the OKI parts work in this case.  


Quoted text here. Click to load it

I'm not familiar with MAT/CAP.  How about when it is a GPIO, is it only
open drain?  


Quoted text here. Click to load it

I am always very leery of using every last pins or sharing pins between
functions.  I want to take a pin from the handshakes for the UART on the
OKI part since I don't have a receiver for that one.  I want an output
to a driver instead.  But I have been told it is a group and can't be
split.  I'll verify this at some point.


Quoted text here. Click to load it

I belive there is both support from the vendor and there seems to be a
large and growing grassroots user base.  I would like to see some of
this for the OKI chips.


Quoted text here. Click to load it

Heck, the Philips and OKI parts are already as cheap if not cheaper than
a lot of the PICs that have much less capabilities.  


Quoted text here. Click to load it

Check with OKI in a few more months.  I have been told Ethernet is the
next one out of the shoot!

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others
says...
Quoted text here. Click to load it

They seem to be a nice fit for some ideas I have for sensors with
reasonably complex data processing.  My last ARM project  collected
a lot of data from various sensors, and did a bunch of statistics,
(medians, percentiles, std. deviations, even some FFT-related
calculations) before storing the data in serial flash memory.   I need
FP calculation speed and RAM size that I couldn't find in an MSP430 or
most 8-bit processors.   The hardware-assisted serial ports on the
AT91R40807 were also quite handy,  but I could probably do without them
if I switched to one of the LPC210X chips.
Quoted text here. Click to load it

Mark Borgerson



Re: arm7 atmel vs others
Quoted text here. Click to load it

Are you saying that the ARM7 chips have floating point?  I was not aware
of that.  Or are you saying that they will emulate floating point much
better than the 8 bitters?  I believe some of the 8 bit chips have
hardware multiply, 8x8 in the MSP430, IIRC.

I am not saying there are NO applications that would benifit from the
LPC20xx chips.  But it just seems like everyone is facinated with them
when they only fit a niche really.  Are these 32 pin MCUs really that
much more versitile than any other device?

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it

In ARM7TDMI the "M" stands for multiply. It is a 32x32->64
multiplication, takes only a few machine cycles. Making such a beast
with a 8x8->16 multiplication (as in MSP430/AVR/PIC) would take
16 multiplications and a big bunch of 8-bit additions. Slooooooow.

I am not aware of any ARM7 -processors with fp, but there is
something like VFP10 coprocessor for ARM10 (Vector Floating Point, IIRC),
which may then be on the same silicon.

We try to make everything with fixed-point arithmetics. The
32-bit resolution it is usually more than enough with real-world
data. Especially the 32-bit MAC operation makes some things
rather enjoyable. For example, a 32-bit fixed-point FFT is not
that slow.

---

Quoted text here. Click to load it
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others


Hmm, I thought it was an 16 x 16 => 32...

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it

Which one? AFAIK, ARM UMLAL et al. commands do make a 32x32 => 64.
There are some severe register limitations, and shifting the
result has to be done bitwise through carry. However, for fixed
point fractional arithmetics the commands are just fine (rounding
can be made with the accumulate part).

The AVR multiplication is 8x8 => 16, but yes, MSP430 may have
16x16 => 32, if that is what you meant.

- Ville

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

Re: arm7 atmel vs others
Quoted text here. Click to load it

No, it takes 9 with a few adds and at least one subtraction.  I
forget the details, but it is in Knuth.  It involves a suitable
factoring of (a + b) * (c + d).

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it

Karashiba (or something) algorithm? It should really work with nine
multiplications, but IIRC it requires full 8-bit subtractions.
This requires some work with the carry bit and absolute values, as
otherwise some information is bound to disappear. Unless the processor
handles this in hw, some manual branching is required..

With large multiplications the algorithm is far superior to the
basic (elementary school) multiplication. If my memory serves,
If my memory serves, its complexity goes as O(n^1.6) whereas
the basic one is clearly O(n^2). However, with shortish
numbers, the overhead may overtake the advange, again depending
on the architecture. (No, I did not bother to write the code
for any real processor, so this is just theoretical babbling :)

It may really be more economical on an AVR/PIC, but the difference
is not very big.

- Ville

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

Re: arm7 atmel vs others
Quoted text here. Click to load it

Does the ARM7TDMI have a 64 bit barrel shifter?  If not, the slow part
of a floating point operation is the normalization.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others
Quoted text here. Click to load it

Only for addition and subtraction.  The results of multiplication
and division normally require at most 2 shifts to normalize.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others
Quoted text here. Click to load it

Yes, but the lack of a barrel shifter is still more significant than the
lack of a 32x32 multiply.  Shifting by one bit is very time consuming.
It is not relevant whether it is in the adds or the multiplies.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it

No such thing. However, as long as the floating point is single
precision fp, there is no real need for a 64-bit barrel shifter.
Multiplications require very little shifting (two positions at max),
so even the clumsy carry shifting works. Adding and subtracting
requires more shifting, but still there is only 24 bits of data,
so everything fits in the 32 bits.

With longer numbers the barrel shifter can be used piecewise,
even though then a temporary register is required. The following pseudo-
code shifts a double word (32+3264% bits) r16:r15 by n bits using the
barrel shifter

  r0 = r15 shr (32 - n)
  r15 = r15 shl n
  r16 = r16 shl n
  r16 = r16 or r15

I guess it is more difficult to find out how much to shift (especially
in subtractions which lose a lot of bits).

Of course, this is not as elegant as a real 64-bit barrel shifter, but
bot very slow, either.

- Ville

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

Re: arm7 atmel vs others

Quoted text here. Click to load it

Ooops. The last row must be:

   r16 = r16 or r0

Maybe it's now better.

- Ville

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

Re: arm7 atmel vs others
says...
Quoted text here. Click to load it

No, they don't have an FPU. (at least the ones I used)  The advantage in
doing standard 32-bit loating point calculations comes from the internal
32-bit egisters.  The ARM DM versions also have 32x32 multiplies and
the ability to do efficient shifts and rotates on 32-bit words.  That
all adds up to running software FP quite a bit faster than 8 or
16-bit processors---even those with hardware multiply instructions.

Some VERY rough benchmarks I ran showed that an ARM 7   at 10Mhz had
about twice the FP performance of  a 68332 at 16Mhz.  Of course, the
ARM was running from internal 32-bit RAM and the 68332 used external
16-bit RAM.
Quoted text here. Click to load it

I would describe the MSP430 as more versatile, but the ARM7 as more
powerful for complex data processing.   That is particularly true
if you want to work with more than 2KBytes of data at a time.


Mark Borgerson



Site Timeline