Forums

An LPC2xxx variant I would like to see

Started by Ken Wada June 3, 2005
ok...
I know that there are some Philips representatives out there. So I am
posting this to this forum.

I want to see an LPC2xxx part that is somewhat of a hybrid between
LPC21xx and LPC22xx.

- PQFP-64 package, (very important!)
- Only lower 10 address lines, however 8 is also acceptable here
- Four chip selects with OE, RD/WR, BLS0/BLS1 control lines
- steal these lines from that used by the ETM port...(almost no one I
know uses these for ETM anyhow)
- 128/256/512 kByte FLASH versions available
- 16/32/64 kByte internal RAM versions available
- similar peripheral feature set as that currently on LPC2214 chip

I for one would most likely recommend the above with 256k FLASH with
64k RAM for most of my current clients.

Ken Wada



An Engineer's Guide to the LPC2100 Series

Hi Ken,

you are correct, our APPS team is reading and posting to this forum.
You mentioned:

* 8-10 address lines
* 4 chip selects
* what width of data bus would you expect?
* would this bus be a mux bus (not so much supported in ARM)?
assuming a mux bus and only 8-bit data / 8-bit address,
* which 12 I/O would you like to be sacrificed for the bus interface?

Our "problem" is that we have too much functionality for the number
of pins. Your request is, do not add pins but add functionality!
The more we multiplex functionality the more we get complaints along
the lines "why did you combine feature A with B and not A with C.

* What would be the use of such a bus? Memory mapped I/O?

My guess is that a non-mux bus would be better suited but adds
immediately 8 pins for the bus.

If we would offer a 80-pin or 100-pin device in TQFP or BGA would
that be something?

Always open to constructive suggestions but I need to know details
and what it would be used for, the applications.

Thanks for expressing your desires here on this forum, we really try
to use all the feedback from here to improve our products according
to your, our customer needs.

btw, did you have a look at the LPC2138 / LPC2136?

Cheers, Robert

--- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
> ok...
> I know that there are some Philips representatives out there. So I
am
> posting this to this forum.
>
> I want to see an LPC2xxx part that is somewhat of a hybrid between
> LPC21xx and LPC22xx.
>
> - PQFP-64 package, (very important!)
> - Only lower 10 address lines, however 8 is also acceptable here
> - Four chip selects with OE, RD/WR, BLS0/BLS1 control lines
> - steal these lines from that used by the ETM port...(almost no one
I
> know uses these for ETM anyhow)
> - 128/256/512 kByte FLASH versions available
> - 16/32/64 kByte internal RAM versions available
> - similar peripheral feature set as that currently on LPC2214 chip
>
> I for one would most likely recommend the above with 256k FLASH
with
> 64k RAM for most of my current clients.
>
> Ken Wada


We would like to see a device comparable to the 2292/2294 but with
more internal flash and RAM (512k/64k perhaps).

Thanks,

JT


Thank you for your feedback. One of the valuable features of this
forum is it allows us to hear these requests from our customers.
Look
for an announcement in December 2005 for a part that should suit your
needs. --- In lpc2000@lpc2..., "johnthomasedwardtimm" <area51@a...>
wrote:
> We would like to see a device comparable to the 2292/2294 but with
> more internal flash and RAM (512k/64k perhaps).
>
> Thanks,
>
> JT


Actually it will be nice to have USB as a part of the device so no external USB chip/connection will be needed and device can work at full speed USB 2.0 Master/slave mode.
This will be really useful as now a days all computer s -- mobile/desktop Any new device with USB built in is a must.....
I am presently using LPC2292/2294 with ISP1181B.

k b shah
----- Original Message -----
From: philips_marketing_usa
To: lpc2000@lpc2...
Sent: Friday, June 03, 2005 3:46 PM
Subject: [lpc2000] Re: An LPC2xxx variant I would like to see Thank you for your feedback. One of the valuable features of this
forum is it allows us to hear these requests from our customers.
Look
for an announcement in December 2005 for a part that should suit your
needs. --- In lpc2000@lpc2..., "johnthomasedwardtimm" <area51@a...>
wrote:
> We would like to see a device comparable to the 2292/2294 but with
> more internal flash and RAM (512k/64k perhaps).
>
> Thanks,
>
> JT

------
Yahoo! Groups Links

a.. To


--- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
wrote:
> Hi Ken,
>
> you are correct, our APPS team is reading and posting to this forum.
> You mentioned:
>
> * 8-10 address lines
> * 4 chip selects
> * what width of data bus would you expect?
--> 16-bit data bus

> * would this bus be a mux bus (not so much supported in ARM)?
--> No, I believe that you can do this without having to MUX

> assuming a mux bus and only 8-bit data / 8-bit address,
> * which 12 I/O would you like to be sacrificed for the bus
interface?
--> As I said, sacrifice the ETM port...almost nobody uses it anyway.

>
> Our "problem" is that we have too much functionality for the number
> of pins. Your request is, do not add pins but add functionality!
--> Actually, my request is to reduce the pin count, and a little bit
of functionality to get a reduced external bus interface with a
reduced footprint.

> The more we multiplex functionality the more we get complaints along
> the lines "why did you combine feature A with B and not A with C.
>
> * What would be the use of such a bus? Memory mapped I/O?
--> Yes, a lot of projects my clients work on make extensive use of
FPGA's with a memory mapped interface.

>
> My guess is that a non-mux bus would be better suited but adds
> immediately 8 pins for the bus.
--> Actually 16-pins for the data, and 10+ pins for address and
control.

>
> If we would offer a 80-pin or 100-pin device in TQFP or BGA would
> that be something?
--> An 80-pin TQFP would be ok. However, an 64-pin PQFP is ideal

>
> Always open to constructive suggestions but I need to know details
> and what it would be used for, the applications.
--> As I said, a low chip-count processor core with some modest means
to do external memory mapped I/O for those FPGA's my clients use.
Actually, an 8-bit data bus with 10-bits of address with chip selects
and control would be ok also.

>
> Thanks for expressing your desires here on this forum, we really try
> to use all the feedback from here to improve our products according
> to your, our customer needs.
>
> btw, did you have a look at the LPC2138 / LPC2136?
--> Yes...but groan, it did not have provisions for doing memory
mapped I/O. Yeah....I know I can probably bit-diddle the memory mapped
I/O and get the thing to work, but usually the HW designers make the
memory mapped I/O for speed...and bit-diddling just defeats the
purpose of having a mem-mapped I/O for speed. We also could have
interfaced the FPGA using the SPI port...but that would have added
more terms in the FPGA that the HW designers could not spare.


Yay!
I knew it! A reduced memory mapped I/O version of the LPC2xxx is
something that I am really looking forward to!

Thanks;
Ken Wada

--- In lpc2000@lpc2..., "philips_marketing_usa"
<philips_marketing_usa@y...> wrote:
> Thank you for your feedback. One of the valuable features of this
> forum is it allows us to hear these requests from our customers.
> Look
> for an announcement in December 2005 for a part that should suit
your
> needs. > --- In lpc2000@lpc2..., "johnthomasedwardtimm" <area51@a...>
> wrote:
> > We would like to see a device comparable to the 2292/2294 but with
> > more internal flash and RAM (512k/64k perhaps).
> >
> > Thanks,
> >
> > JT


Yes...
An integrated USB port would be very nice also.

--> Get rid of the ETM port, (almost no one uses it), and convert the
ETM pins into a reduced mem-map interface and USB 2.0?

Plus more internal RAM. We are always needing more internal RAM space.

How does that sound?

Ken Wada

--- In lpc2000@lpc2..., "k b shah \(lascaux\)" <kbshah@l...>
wrote:
> Actually it will be nice to have USB as a part of the device so no
external USB chip/connection will be needed and device can work at
full speed USB 2.0 Master/slave mode.
> This will be really useful as now a days all computer s --
mobile/desktop Any new device with USB built in is a must.....
> I am presently using LPC2292/2294 with ISP1181B.
>
> k b shah
> ----- Original Message -----
> From: philips_marketing_usa
> To: lpc2000@lpc2...
> Sent: Friday, June 03, 2005 3:46 PM
> Subject: [lpc2000] Re: An LPC2xxx variant I would like to see > Thank you for your feedback. One of the valuable features of this
> forum is it allows us to hear these requests from our customers.
> Look
> for an announcement in December 2005 for a part that should suit
your
> needs. > --- In lpc2000@lpc2..., "johnthomasedwardtimm" <area51@a..
.>
> wrote:
> > We would like to see a device comparable to the 2292/2294 but
with
> > more internal flash and RAM (512k/64k perhaps).
> >
> > Thanks,
> >
> > JT
----------------------------------
--------
> Yahoo! Groups Links
>
> a.. To >
>



It would be much better if the I/O could be re-mappable so I could
get more PWM channels AND still be able to use both UARTS. As it is
now I can only use 2 out of 6 PWM channels when using both UARTS.

That'd be much easier than toggling pins with PWM sotware interrupts.

BoB
--- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
> Yes...
> An integrated USB port would be very nice also.
>
> --> Get rid of the ETM port, (almost no one uses it), and convert
the
> ETM pins into a reduced mem-map interface and USB 2.0?
>
> Plus more internal RAM. We are always needing more internal RAM
space.
>
> How does that sound?
>
> Ken Wada
>
> --- In lpc2000@lpc2..., "k b shah \(lascaux\)"
<kbshah@l...>
> wrote:
> > Actually it will be nice to have USB as a part of the device so
no
> external USB chip/connection will be needed and device can work at
> full speed USB 2.0 Master/slave mode.
> > This will be really useful as now a days all computer s --
> mobile/desktop Any new device with USB built in is a must.....
> > I am presently using LPC2292/2294 with ISP1181B.
> >
> > k b shah
> > ----- Original Message -----
> > From: philips_marketing_usa
> > To: lpc2000@lpc2...
> > Sent: Friday, June 03, 2005 3:46 PM
> > Subject: [lpc2000] Re: An LPC2xxx variant I would like to see
> >
> >
> > Thank you for your feedback. One of the valuable features of
this
> > forum is it allows us to hear these requests from our
customers.
> > Look
> > for an announcement in December 2005 for a part that should
suit
> your
> > needs.
> >
> >
> > --- In lpc2000@lpc2..., "johnthomasedwardtimm"
<area51@a..
> .>
> > wrote:
> > > We would like to see a device comparable to the 2292/2294 but
> with
> > > more internal flash and RAM (512k/64k perhaps).
> > >
> > > Thanks,
> > >
> > > JT
> >
> >
> >
> >
> >
> --------------------------------
--
> --------
> > Yahoo! Groups Links
> >
> > a.. To
> >
> >
> >
> >


I agree that the ETM port isn't needed for many applications. However
we're using it to debug a control system where a LPC2214 is doing
closed loop control of a large hydraulic load. Under most situations
we can't break then single step our code. The ETM was the main reason
why we chose the LPC22xx series over the other ARM devices out there.

Philips_apps:
please don't ditch the ETM! If anything, an ETM with data trace would
be even better

--- In lpc2000@lpc2..., "Ken Wada" <kwada@a...> wrote:
> --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...>
> wrote:
> > Hi Ken,
> >
> > you are correct, our APPS team is reading and posting to this
forum.
> > You mentioned:
> >
> > * 8-10 address lines
> > * 4 chip selects
> > * what width of data bus would you expect?
> --> 16-bit data bus
>
> > * would this bus be a mux bus (not so much supported in ARM)?
> --> No, I believe that you can do this without having to MUX
>
> > assuming a mux bus and only 8-bit data / 8-bit address,
> > * which 12 I/O would you like to be sacrificed for the bus
> interface?
> --> As I said, sacrifice the ETM port...almost nobody uses it
anyway.
>
> >
> > Our "problem" is that we have too much functionality for the
number
> > of pins. Your request is, do not add pins but add functionality!
> --> Actually, my request is to reduce the pin count, and a little
bit
> of functionality to get a reduced external bus interface with a
> reduced footprint.
>
> > The more we multiplex functionality the more we get complaints
along
> > the lines "why did you combine feature A with B and not A with C.
> >
> > * What would be the use of such a bus? Memory mapped I/O?
> --> Yes, a lot of projects my clients work on make extensive use of
> FPGA's with a memory mapped interface.
>
> >
> > My guess is that a non-mux bus would be better suited but adds
> > immediately 8 pins for the bus.
> --> Actually 16-pins for the data, and 10+ pins for address and
> control.
>
> >
> > If we would offer a 80-pin or 100-pin device in TQFP or BGA would
> > that be something?
> --> An 80-pin TQFP would be ok. However, an 64-pin PQFP is ideal
>
> >
> > Always open to constructive suggestions but I need to know
details
> > and what it would be used for, the applications.
> --> As I said, a low chip-count processor core with some modest
means
> to do external memory mapped I/O for those FPGA's my clients use.
> Actually, an 8-bit data bus with 10-bits of address with chip
selects
> and control would be ok also.
>
> >
> > Thanks for expressing your desires here on this forum, we really
try
> > to use all the feedback from here to improve our products
according
> > to your, our customer needs.
> >
> > btw, did you have a look at the LPC2138 / LPC2136?
> --> Yes...but groan, it did not have provisions for doing memory
> mapped I/O. Yeah....I know I can probably bit-diddle the memory
mapped
> I/O and get the thing to work, but usually the HW designers make
the
> memory mapped I/O for speed...and bit-diddling just defeats the
> purpose of having a mem-mapped I/O for speed. We also could have
> interfaced the FPGA using the SPI port...but that would have added
> more terms in the FPGA that the HW designers could not spare.