Yahoo Groups archive

Lpc2000

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

Message

Re: LPC hardware+software problems

2006-05-01 by John Heenan

More misleading and bizarre statements with regard to fundamental 
facts.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@> wrote:
> >
> > I only
> > need simple features:
> > - Reliable Code Read Protection.

> The designs I have seen where client does not want the product 
cloned
> by copying hardware and the software, especially when software is 
the
> value item, do not use LPCs.  AVRs seem to be the popular choice.


This is misleading. To their credit ATMEL AVRs were the first in with 
an easily usable 'library' software to support updating firmware that 
has been encrypted. Microchip now have encryption libraries for PIC 
firmware.

ATMEL also makes its easier not to stuff up through the use of 'boot 
sectors' and relocatable interrupt destinations in the AVR.

None of these make AVRs interpedently more or less secure with regard 
to code read protection and there is nothing which prevents 
equivalent end functionality in other processors.

Hardware copying cannot be stopped, unless part ids are removed.

> 
> As for flash speed, I understand LPC is not as fast as SAM and maybe
> even OKI.  Have a look at guaranteed speeds and write/erase times.  
I
> dont know why you consider LPC flash as fastest.

This is bizarre. It is well known and accepted execution from flash 
is 'fast' in LPCs. The MAM is a well publicised feature of the LPC.

To quote from the manual:

"Simply put, the Memory Accelerator Module (MAM) attempts to have the 
next ARM instruction that will be needed in its latches in time to 
prevent CPU fetch stalls."

While flash speed maxes out, Philips made a clever decision to allow  
more flash contents (128 bits) to be grabbed than required 
immediately, while not implementing a full featured cache.

> The other reason to stay away from LPC flash is that it is in its
> infant stage -- there are a number of implementation bugs to be 
ironed
> out before it becomes as usable like other flash architectures.  At
> the moment it is good for OTP needs but with the advantage that 
field
> upgrades are possible.
> 
> Jaya
>

To suggest that Philips sells products with infant stage flash just 
beggars belief.

To also suggest there is even a remote hint on consensus of this is 
irresponsible.

John Heenan

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.