arm7 atmel vs others

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

"Rick" <rick@skyko.com> skrev i meddelandet
news:r3uXb.21596$1S1.20395@nwrddc01.gnilink.net...
> 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 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
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

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


For external bus versions also look at (sampling stage):

http://my.semiconductors.philips.com/pip/LPC2194JBD64.html
http://my.semiconductors.philips.com/pip/LPC2210FBD144.html
http://my.semiconductors.philips.com/pip/LPC2214FBD144.html
http://my.semiconductors.philips.com/pip/LPC2290FBD144.html
http://my.semiconductors.philips.com/pip/LPC2292FBD144.html

From a Robert Buadu post in the LPC21xx forum:

http://groups.yahoo.com/group/lpc2100/


Regards,
Arie de Muynck

Rick wrote:
> 
> 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.

All flash is pretty slow.  I'm not sure why this is, but I know even
with the onboard flash it is slow. 

> 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 Philips LPC2xxx chips have "0 wait state" flash, but don't belive
that it is truely 0 wait state.  They fetch 128 or 256 (I don't remember
which) bits from Flash at one time.  But in essence, this works like a
multiple level pipeline, you have to ask for the fetch multiple clock
cycles in advance of needing it.  On instruction fetches this is fine
until you have a branch, then the current 256 bit word and the one being
fetched have to be thrown away and a new fetch started.  If it is a data
access, it won't begin until; 1) it is requested and 2) the current
fetch completes (I assume).  So the wide word technique helps, but don't
count your clock cycles until they are measured.  :)  

A cache will likely do as much good and works for all memory, not just
the Flash.  


> 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 thought you needed 8 channels of ADC?  Doesn't the LPC2214 only have
4?  Don't assume that these ADC will give you the full range of the bits
counted.  Many ADC claim a given number of bits for resolution, but the
AC characteristics leave a lot to be desired.  I suggest that you use
both external ADC and DACs and keep them well separated from the digital
portions of your design, unless you really don't need much accuracy and
the noise is not an issue.  


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

I have been told late this year.  They have the 2114 and 2124 out now. 
But they were supposed to have these parts in the very small HN64
packages, but that has been delayed without explanation.  

Take another look at the OKI ML67Qxxxx parts.  The 4000 series runs at
33 MHz and the 5000 series runs at 60 MHz and has on chip cache.  The
URL is http://www2.okisemi.com/us/docs/MCUTables-9.html.  Avoid the main
site and stick with the US site.  OKI can have some pretty messed up web
stuff.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

"Ulf Samuelsson" <ulf@atmel.nospam.com> wrote in message
news:GxJXb.309$EV2.2933@amstwist00...
> "Rick" <rick@skyko.com> skrev i meddelandet
> news:r3uXb.21596$1S1.20395@nwrddc01.gnilink.net...
> > 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 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.
>
>

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

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:402F347C.9400C1CF@yahoo.com...
> Rick wrote:
> >
> > 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.
>
> All flash is pretty slow.  I'm not sure why this is, but I know even
> with the onboard flash it is slow.
>
> > 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 Philips LPC2xxx chips have "0 wait state" flash, but don't belive
> that it is truely 0 wait state.  They fetch 128 or 256 (I don't remember
> which) bits from Flash at one time.  But in essence, this works like a
> multiple level pipeline, you have to ask for the fetch multiple clock
> cycles in advance of needing it.  On instruction fetches this is fine
> until you have a branch, then the current 256 bit word and the one being
> fetched have to be thrown away and a new fetch started.  If it is a data
> access, it won't begin until; 1) it is requested and 2) the current
> fetch completes (I assume).  So the wide word technique helps, but don't
> count your clock cycles until they are measured.  :)
>
> A cache will likely do as much good and works for all memory, not just
> the Flash.
>
>
> > 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 thought you needed 8 channels of ADC?  Doesn't the LPC2214 only have
> 4?  Don't assume that these ADC will give you the full range of the bits
> counted.  Many ADC claim a given number of bits for resolution, but the
> AC characteristics leave a lot to be desired.  I suggest that you use
> both external ADC and DACs and keep them well separated from the digital
> portions of your design, unless you really don't need much accuracy and
> the noise is not an issue.
>
>
> > 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?
>
> I have been told late this year.  They have the 2114 and 2124 out now.
> But they were supposed to have these parts in the very small HN64
> packages, but that has been delayed without explanation.
>
> Take another look at the OKI ML67Qxxxx parts.  The 4000 series runs at
> 33 MHz and the 5000 series runs at 60 MHz and has on chip cache.  The
> URL is http://www2.okisemi.com/us/docs/MCUTables-9.html.  Avoid the main
> site and stick with the US site.  OKI can have some pretty messed up web
> stuff.
>
>
> -- 
>
> Rick "rickman" Collins

Hi again Rick,

I did as you suggested and took another look at the OKI part.  That is a very
nice chip...it has about everything I need, is in stock at the distributor (that
is a nice feature!) and is in the same price range as the other parts (about $14
for a ML67Q5003).  I should have listened to you earlier.  :-)

So, how well does the SDRAM interface work?  It states the device supports a
glueless connection to up to 64MB of SDRAM via its memory controller.  That
sounds like a cheap way to get a boatload of highspeed memory...

I will dig into the data sheet and any app notes some more.  Thanks for all your
help!

Rick

rickman wrote:

> Rick wrote:
> 
<snip>
> 
>>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 Philips LPC2xxx chips have "0 wait state" flash, but don't belive
> that it is truely 0 wait state.  They fetch 128 or 256 (I don't remember
> which) bits from Flash at one time.  But in essence, this works like a
> multiple level pipeline, you have to ask for the fetch multiple clock
> cycles in advance of needing it.  On instruction fetches this is fine
> until you have a branch, then the current 256 bit word and the one being
> fetched have to be thrown away and a new fetch started.  If it is a data
> access, it won't begin until; 1) it is requested and 2) the current
> fetch completes (I assume).  So the wide word technique helps, but don't
> count your clock cycles until they are measured.  :)  
> 
> A cache will likely do as much good and works for all memory, not just
> the Flash.  

  Not quite. Fundamental memory bandwidth matters, so while you are 
right that a branch will be the slowest, the CPU MIPS across blocks is 
determined by nett memory bandwith.
  Thus the wider, on chip FLASH will give much higher performance than
a narrower, off chip solution.

  It does mean that cycle-determentistic operation is unlikely, so users
comming from smaller uC should be aware of that.

-jg

Rick wrote:
> 
> Hi again Rick,
> 
> I did as you suggested and took another look at the OKI part.  That is a very
> nice chip...it has about everything I need, is in stock at the distributor (that
> is a nice feature!) and is in the same price range as the other parts (about $14
> for a ML67Q5003).  I should have listened to you earlier.  :-)

I don't know what your volumes are, but I have seen prices of under $10
on this part.  Check with your distributors.  Often they give you up to
20% off just by asking.  I find that waiting a few weeks and asking
again can get you another 10% off if you say you are making a final
decision. 


> So, how well does the SDRAM interface work?  It states the device supports a
> glueless connection to up to 64MB of SDRAM via its memory controller.  That
> sounds like a cheap way to get a boatload of highspeed memory...
> 
> I will dig into the data sheet and any app notes some more.  Thanks for all your
> help!

I have an eval board from OKI, but I have done nothing with it since it
pretty much requires a full development system to make it do anything. 
I have a board on order from Cogent, but I am getting tired of waiting
on them too.  I'm not sure what their story is.  I need to call them
this week.  

There is an English company making a new dev board, but it is not ready
yet.  I plan to do our software in Forth which is not commonly
supported.  I found New Micros (NMI) who sells several (or many even)
boards hosting Forth.  They are working on an ARM board with Forth using
the Philips chip.  I am trying to talk them into using the OKI chip. 
You might want to send them an email asking about an OKI ARM board.  The
more people ask, the more likely they are to make something.  

Right now most of the small boards will use the Philips chip because it
is so small.  But it is too small for a lot of stuff.  It really is much
more like one of the 8 bit MCUs.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Jim Granville wrote:
> 
> rickman wrote:
> 
> > Rick wrote:
> >
> <snip>
> >
> >>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 Philips LPC2xxx chips have "0 wait state" flash, but don't belive
> > that it is truely 0 wait state.  They fetch 128 or 256 (I don't remember
> > which) bits from Flash at one time.  But in essence, this works like a
> > multiple level pipeline, you have to ask for the fetch multiple clock
> > cycles in advance of needing it.  On instruction fetches this is fine
> > until you have a branch, then the current 256 bit word and the one being
> > fetched have to be thrown away and a new fetch started.  If it is a data
> > access, it won't begin until; 1) it is requested and 2) the current
> > fetch completes (I assume).  So the wide word technique helps, but don't
> > count your clock cycles until they are measured.  :)
> >
> > A cache will likely do as much good and works for all memory, not just
> > the Flash.
> 
>   Not quite. Fundamental memory bandwidth matters, so while you are
> right that a branch will be the slowest, the CPU MIPS across blocks is
> determined by nett memory bandwith.
>   Thus the wider, on chip FLASH will give much higher performance than
> a narrower, off chip solution.

I think there are too many other variables for you to make that claim
with a certainty.  As I pointed out, the memory bandwidth has a high
waste factor when branching occurs *OR* the processor needs data from
the flash.  You can't say this will be faster than a cached Flash unless
you run a specific benchmark.  A lot of funny things happen when you
actually run code.  

BTW, no one was comparing off chip Flash.  The comparison is on chip,
wide Flash vs. on chip, narrow Flash with cache.  


>   It does mean that cycle-determentistic operation is unlikely, so users
> comming from smaller uC should be aware of that.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

On 2004-02-14, Ulf Samuelsson <ulf@atmel.nospam.com> wrote:
> 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.

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