Lpc2000

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@yahoogroups.com, "Ken Wada" <kwada@a...> wrote:
> --- In lpc2000@yahoogroups.com, "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.