Lpc2000

--- In lpc2000@yahoogroups.com, "raweaver06" <raweaver00@...> wrote:
> My app's are typically very heavily math oriented (I will even use 
> software floating point more often with a strong CPU to speed up 
> development time) so a 32 bit architecture I feel will be of great 
> benefit here.  I don't do much I/O bit twiddling, mostly CAN I/0 
> communication which can now be done in two register reads instead of 
> my current 4.   So, now that I've been re-assured that LPC doesn't 
> carry much of a penalty in FLASH, I'll keep up my heavy reading in 
> ARM architucture and learning.  Thanks for the info.
>

Given what you say (heavy math, light bit-twiddling I/O), you should 
see a good improvement. Your figure of 52 MIPS for a 60 MHz clock is 
about right for the LPC2000 series (I believe some of the newer 
varients can be clocked even faster). The exact MIPS figure depends on 
the instruction mix: although it's called a RISC, in fact many ARM 
instructions take more than one cycle to complete. 

We did fairly extensive benchmarking of various 32-bit micros: the 
LPC2000 parts are pretty good. Note that you don't get 100% of the 
memory bandwidth with the MAM running from flash, but it's not far off 
it (again, exact figures hard to say, due to differences in the number 
of branches). Some other ARM parts are **very** slow running from 
flash.

Three other recommendations:

1. Given it's a 32-bit part, you might want to look at fixed-point 
math. A bit trickier to handle, but much faster on anything without 
floating-point hardware.

2. You might want to do some benchmarking on a simulator: again, from 
experience, published benchmarks mean little: you really need to look 
at what your application is doing. If you code up and measure the 
innermost loops you can get a fair idea of total MIPS.

3. Like all RISCS, compilers make a **huge** difference on ARM: with 
optimisation off, it'll run like a dog, with full optimisation, you'd 
be hard placed to hand-code in assembler more efficient code (I'm not 
saying you can't, but you probably don't have to bother). The downside 
is that debugging highly optimised code with an ICE can be quite a 
challange. Because of this we stick to ANSI 'C' and debug all our math 
stuff on a PC first.

Hope this helps.

By the way, what is the application area you're working on?

Brendan