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