Lpc2000

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> --- 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
>

Sensor fusion, usually radars and now vision is to be added in.