Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

RE: [lpc2000] Why pick ARM? (Sorry about the open ended-ness of this question)

2005-12-19 by Dan Beadle

All I do is embedded.  I have used a lot of different ARM systems -
ARM7/ARM9, etc.

 

Prior to moving to Philips ARM product line, most product were built
around 8051 or PIC derivatives.  The perpetual problem was running out
of horsepower and / or memory space.  I helped on an avionics product
that took 5x longer than it should have simply because of the difficulty
of debugging banked memory architectures.  But there was not good
alternative at the time.  Most embedded cpus were limited to 64K address
space (certainly not all - but most).  So they struggled.

 

The LPC line solves the 8051 memory limitations.  We have found that
8051 code size is a good indicator of ARM size - usually about the same
to 1.5x larger (but we have much more room available).  Then there is
the mater of horsepower - clock speed on the LPC is about 3-8x faster
(depending on the 8051 used for comparison).  And with 32 bit words, we
pick up more horsepower.  Better instructions, etc....

 

Certainly there are other offerings - OKI, ATMEL and TI all have great
little embedded ARM CPUs. 

 

I have also used ARM9 from Sharp.  The selection criteria for that has
always been LCD driver.  It is not as nice for small embedded, but is
great for products requiring a user interface. BOM costs go up quickly
due to external flash and SDRAM costs, but you end up with a lot of
horsepower for not much money.

 

 

The key advantage of the ARM system is the multiple vendors using the
same CPU architecture and customizing their own SOC features.  Philips
is going after deep embedded. Sharp is going after small video devices,
Oki is a little up-scale from Philips.  So invest once in development
tools and learning and apply it to a lot of different vendor offerings,
depending upon the product requirements (and not on the CPU with which
you feel most comfortable)  This is the key argument against products
like the H8 and other proprietary designs.

 

Finally, why not x86?  It has some merits - if you port Windows or Linux
to it. Then you get all the rich tools, etc. But you also get all the
overhead.  Not a good fit,  in my opinion, for deep embedded.  

 

So, pick your goals and requirements, then pick the CPU.  Tiny = ARM7,
Linux pretty much requires ARM9, Windows... oh well....

 

Hope this helps


Dan Beadle

 

 

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of nma550n
Sent: Monday, December 19, 2005 12:11 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Why pick ARM? (Sorry about the open ended-ness of
this question)

 

Hello there!

First off, I'd like to say it's great to finally come across a decent
message board like this. 

Sorry about this question, it probally gets asked all the time.
However, I have looked around the archives for a fair bit, and haven't
found anything (loads of messages).

Through-out university and through the grape-vine, I keep hearing
about how great ARM cores are. I can see they are used in many popular
devices and such.
I have not yet had commited myself to developing with this core as I
feel a bit overwelmed with all the other alternatives out there and
don't want to ignorantly be swayed by good marketing.

Does anyone know of a NON-BIASED webpage, or resource where there is a
comparison of Modern Microcontrollers?

Also as a second question, why did you decide on ARM?

Sounds very marketing, and I can assure you I do not work for any
company, only hobby interests.

Cheers

Nick








  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



[Non-text portions of this message have been removed]

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.