arm7 atmel vs others

Jukka Marin wrote:
> 
> 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..)

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


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

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

-- 

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-18, rickman <spamgoeshere4@yahoo.com> wrote:
> 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.  :)

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

>> 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).
>
> What do you mean about "intelligence"?  Are you talking about the
> features on the chip or the support from the vendor? 

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 I&#4294967295;C 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 I&#4294967295;C 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

Jukka Marin wrote:
> 
> On 2004-02-18, rickman <spamgoeshere4@yahoo.com> wrote:
> > 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.  :)
> 
> 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?)

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.  


> >> 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).
> >
> > What do you mean about "intelligence"?  Are you talking about the
> > features on the chip or the support from the vendor?
> 
> 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.

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.  


> Also, the I&#4294967295;C 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 I&#4294967295;C 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.

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


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

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. 


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

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. 


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

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


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

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

-- 

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

Jukka Marin wrote:
<snip>
> 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.

  Sounds like an oops, but could be to protect you from yourself, as the
'INT then Check' is not guaranteed to give the correct answer.
  As chips get larger, they loose the time-determinism of smaller uC, so 
this design need method needs some modify.

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

  Zilog have that (not quite64KB), in the eZ80, and there are 80C51's 
with Ethernet on-chip, so I'm sure ARM variants will be 'in the works'.

-jg

In article <4033E0F3.A52DC1B4@yahoo.com>, spamgoeshere4@yahoo.com 
says...
> Jukka Marin wrote:
> > 
> > On 2004-02-18, rickman <spamgoeshere4@yahoo.com> wrote:
> > > 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.  :)
> > 
> > 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?)
> 
> 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.  
> 
> 

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.
> > >> 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).
> > >
> > > What do you mean about "intelligence"?  Are you talking about the
> > > features on the chip or the support from the vendor?
> > 
> > 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.
> 
> 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.  
> 
> 
> > Also, the I&#4294967295;C 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 I&#4294967295;C 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.
> 
> I'm not familiar with MAT/CAP.  How about when it is a GPIO, is it only
> open drain?  
> 
> 
> > 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 ;-)
> 
> 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. 
> 
> 
> > Umm.. "support from the vendor".. Is there such a thing for the Philips
> > chips? :-)
> 
> 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. 
> 
> 
> > 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).
> 
> Heck, the Philips and OKI parts are already as cheap if not cheaper than
> a lot of the PICs that have much less capabilities.  
> 
> 
> > Somebody make a small chip with 256 kB or more FLASH, 64 kB SRAM,
> > 10/100 Mbps Ethernet and some UARTs, timers etc.. :-)
> 
> Check with OKI in a few more months.  I have been told Ethernet is the
> next one out of the shoot!
> 
> 

Mark Borgerson

Mark Borgerson wrote:
> 
> 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.

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

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

Jukka Marin wrote:

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

This new Infineon TC1130 device looks 'packed'
One of the few I've seen with all 3 : Ethernet/CAN/USB

- 10/100 Ethernet
- USB
- 4 x CAN
- many Serial ports
- MMU and FPU
- Runs Linux
- 144K RAM
- 200 MIPS
- 64 bit local bus
- price e12.05/10K

http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid=50588&cat_oid=-8138

[No flash]
-jg

rickman <spamgoeshere4@yahoo.com> writes:

> Are you saying that the ARM7 chips have floating point?

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.

---

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

They aren't. However, if you need multi-threading or fast or high-
precision calculation, you may be best off with a small 32-bitter.
Or if you need fast bit-banging, they may still be the most economical
solution.

Of course, avarything depends on the cost, but it seems that e.g. the
Philips chips give a very good value for the price compared to high-end
8-bit processors. (If they were available, that is :)

There are even some less-obvious niches, such as low-power computing.
An ARM at 4 MHz consumes very little power but is still very
powerful in some tasks.

---

Using the 32-bit processors just out of the joy of it does not seem
to be reasonable. The world is full of small solutions where a simple
8-bitter offers an easy way to live. The larger processors are
more complicated and require more effort in the s/w development.

Inexpensive 32-bit processors may disturb some high-end 8-bit processors
(e.g. large AVRs), but they cannot challenge the small ones.

- Ville

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

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

//-------------------

As someone who uses PIC/AVR/8051 on a regular basis, the Philips and OKI 
parts are really attractive, however getting hold of them easily is a 
real issue at present.  Most of the projects I work on involve small 
quantities (ie. a couple hundred), and as a result, I tend to be pretty 
low priority to the distribution companies.  Component availability is 
therefore a prime consideration when choosing parts.

I can buy PICs or 8051 from a large number of sources in the UK in any 
quantity, without any hassle.  If I can't buy the exact part, chances 
are a similar version is available which is pin and code compatible. 
AVR is a little more difficult, especially if you want access to the 
full range, but if I can't get them locally, then Digikey give me 
excellent service.

We have looked at the Philips range and have a dev board which we have 
been using to evaluate various tool chains, and from a technical 
standpoint, I'm really like it (apart from the lack of code protection).

I think Philips need to get this range into the catalogue suppliers like 
Farnell and Digikey, at which point it should really take off.

Martin

"Ville Voipio" <vvoipio@kosh.hut.fi> skrev i meddelandet
news:i3kllmz5sat.fsf@kosh.hut.fi...
> rickman <spamgoeshere4@yahoo.com> writes:
>
> > Are you saying that the ARM7 chips have floating point?
>
> 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.
>

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

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