Lpc2000

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> I've seen a lot of "move to another processor" here.

I did not realise I said this so many times in one post!  Must be I
was trying to tell the poster something ... :)

> I'm trying hard to do that but could not.

Having already made the selection, you have to weigh costs of moving
against maintaining status quo.

I have see two cases where having made the selection, they had to move:

1/  Student Lab Kit:  LPC does not allow flash to be locked down. 
Students could (deliberately) destroy the hardware by corrupting boot
sector.  They switched to OKI.

2/  Flash Data Storage:  LPC does not allow flash to be written at
units of byte or words.  The 16-bit write requirement, ad hoc block
sizes for 256K parts coupled with its life cycle made it unsuitable
for data storage.  I am not sure if they switched to OKI or SAM.

In both cases, it did not look like the switch was more expensive.

A third case is pending on what Robert and Tom have to say about UART
issues in LPC family.

[Note that Philips has not indicated the UART bugs can be fixed, or
that it will be fixed, unlike power on reset bug.]

A fourth case is pending on what happens in July in relation depletion
of LPC stocks in the field.

> Since you are the 
> expert, could you find me an alternate ARM7 good enough??  I only
> need simple features:
> - Reliable Code Read Protection.
> - Around 48 I/O on a LQFP64 package. The other chips are having 
>   <50% of pins as I/O
> - Good to have 1x Clock execution cycle at 60MHz but can go 
>   without it
> - Flash size 32K to 256KB, SRAM 8KB to 32KB
> - Competitive pricing.
> - (All USB, UART, SPI, I2C, PWM, Timers, watchdog are standard on 
>   all chips.   All parts have buggy peripherals but all can be
>   fixed.  What the big problem/fuss??)

Flattery will not get me doing the selection chart for you :)

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.

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.

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.

Hope this helps.

Jaya