Yahoo Groups archive

Lpc2000

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

Message

Re: [lpc2000] Compatibility

2004-12-16 by microbit

Hi Al,

[snip here and there]

> Hi Kris, I'm not even sure the ARM is what I want. It seems underdone - 
> overkill if you see what I mean. Not as bad as some other ARM devices, 
> but still too much of some things and not enough of others.

My interest had been with ARM since quite some time, but it always seemed to
mean getting hundreds of pins, and all sorts of periphs I just don't need.
That's changed a lot now.
My ongoing focus on ARM is because the next generation of RF single chip
with on-board ARM core should not be *that* far away.
So I'd better start learning.

Curiously enough, the first time I compiled the Basic interpreter, same C code
as MSP430 (IOW not specifically optimized for ARM), it didn't run _that_
awfully much faster than MSP430 at same clock.
Once things are optimized, and you go to 60 MHz, then .... geez, it flies...

> parts to get an ADC, and even then it's only 10 bits. To me it's XA'ish. 

Well at least it doesn't suck 100 mA like XA did :-) (at 30 MHz)
Is/was a shame of XA really. Whatever happened there ?
As soon as XA came out I bought the Hitech-C compiler.
In those days when Philips still owned CoolRunner, my FAE told me that
Philips was - at that time - the ONLY vendor with MCU IP core and ultra low
power CPLD.
The thought of an XA + large CPLD in one chip was beckoning .... 

>   A good idea done badly. Philips rationale for low res ADC is that on 
> chip noise makes anything more useless. Its odd that most other vendors 
> don't have problems here, 

To be fair, I recall the (IIRC) ATmega163 blowing back by 2 yrs or so, supposedly
one of the main reasons was massive ADC problems.
I think they ended up changing the bond-out/pinout alltogether to get the noise down.
Those days were weird, one part you could get but there was no datasheet, the other
you couldn't get and yet there was a datasheet on Web.

> looking at the ARM is it's flash base and higher execution speeds. 
> Couple that with 32 bit processing (which I could live without) for fast 
> calcs. 

You can always run in 16 bit Thumb mode, but ISRs must be in ARM mode  :-)

> or better, 8 capture compares, 1 UART, 1 SPI/IIC. 60MHz, slower I/O is 
> fine. I just want the built in multiplier. Philips don't even come close 
> on their road map.

The ARM instr set had a fast multiply I thought ?

> So, although I'm having a look I don't see much of a future in it for 
> me. There are better, lower cost options on the horizon, that approach 
> the same processing speeds, at lower currents, with a more rational (for 
> me) peripheral/memory mix.

I understand.
The appeal for me is in the large amouint of on-board SRAM.

-- Kris


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