Lpc2000

Hi all,

this group has been such a great pool of help for each other and also 
for us at Philips. Some of the questions trigger internal design 
investigations, changes in documentation, slides for presentations 
and so on. Be assured we are reading and even participating.  
The "Philips_Apps" ID is used for "official" purposes only by several 
members of our technical team.

Today I would like to pick your brains and get the top-ten charts of 
most wanted features in future LPC2000 devices. I promise this will 
have an impact on product definition planning if a large number of 
you participate. 

By the way, some of the listed features are already in development 
but we would like to have confirmation we are working on the right 
things. The majority in the list however is totally open whether the 
features will be implemented in the future or not, your vote counts. 
Last but not least let me tell you that the price tag for these 
options is very different, e.g. doubling the memory size is a lot 
more expensive than adding a serial interface. 

Thank you for the great community in the group and for your help 
planning upcoming devices. 

Looking forward to your numerous responses, Robert

>Hi all,
>
>this group has been such a great pool of help for each other and also
>for us at Philips. Some of the questions trigger internal design
>investigations, changes in documentation, slides for presentations
>and so on. Be assured we are reading and even participating. 
>The "Philips_Apps" ID is used for "official" purposes only by several
>members of our technical team.
>
>Today I would like to pick your brains and get the top-ten charts of
>most wanted features in future LPC2000 devices. I promise this will
>have an impact on product definition planning if a large number of
>you participate.
>
>By the way, some of the listed features are already in development
>but we would like to have confirmation we are working on the right
>things. The majority in the list however is totally open whether the
>features will be implemented in the future or not, your vote counts.
>Last but not least let me tell you that the price tag for these
>options is very different, e.g. doubling the memory size is a lot
>more expensive than adding a serial interface.

  I have a few wishes so I'll start with the practical and move from
  there:
    1. Smaller windows into flash so that it can be programmed on a
       finer scale.  Erasing and reprogramming 2K chunks at a time
       is wasteful and 64K chunks are even clumsier.
    2. Don't kill all the flash when programming part of it so that
       the processor can still run code from part of flash while
       programming another.
    3. Programmable blocks instead of all possible peripherals.
       This might take the form of an FPGA and it should come with
       basic programs to implement all the peripherals offered now.
       But it would allow new ways of combining them or one could
       use the programmable logic to extend processor operations or
       implement a different type or number of peripherals.
    4. Digital to Analog converter.
    5. Analog building blocks so that they can be used to process
       analog signals before converting or perhaps some of the analog
       building blocks would be used to make an A/D converter.
    6. On-chip BlueTooth or wireless connection so no cables are
       needed.

  Rob

Additional to the poll I would like to see:

small pin count devices (20pins, 8pins) with powerful high speed serial
interfaces (ADC, DAC, I2C-slave, SPI, async - dont strip down the serial
part) - usage as sub controller could simplify designs

integrated 1.8v regulator (mandatory for low pin counts)

2.4GHz RF parts (prefered band, because it is available worldwide)

high res ADC's

schmitt trigger for all inputs

integrated analog parts (comparators, OPamps)

(RTC should have <2uA ;-)

        Matthias

Oh oh oh ! !

I forgot THE most important thing of all kind !  :D

an LCD controller !!!

I know Philips makes them already but having them inside and being able to
drive for instance a 640x480 panel maybe even with colour or monochrome
would be some of the most awsome thing ... we use Samsung S3BOX44 arm with a
mean lcd controller but could philips come up with something similar that
would simply be perfect.

Best regards
Lasse Madsen



-----Oprindelig meddelelse-----
Fra: philips_apps [mailto:philips_apps@...]
Sendt: 17. juni 2004 01:46
Til: lpc2000@yahoogroups.com
Emne: [lpc2000] New Poll started with Wish-List for future devices


Hi all,

this group has been such a great pool of help for each other and also
for us at Philips. Some of the questions trigger internal design
investigations, changes in documentation, slides for presentations
and so on. Be assured we are reading and even participating.
The "Philips_Apps" ID is used for "official" purposes only by several
members of our technical team.

Today I would like to pick your brains and get the top-ten charts of
most wanted features in future LPC2000 devices. I promise this will
have an impact on product definition planning if a large number of
you participate.

By the way, some of the listed features are already in development
but we would like to have confirmation we are working on the right
things. The majority in the list however is totally open whether the
features will be implemented in the future or not, your vote counts.
Last but not least let me tell you that the price tag for these
options is very different, e.g. doubling the memory size is a lot
more expensive than adding a serial interface.

Thank you for the great community in the group and for your help
planning upcoming devices.

Looking forward to your numerous responses, Robert





Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
> Hi all,
> 
> this group has been such a great pool of help for each other and 
also 
> for us at Philips. Some of the questions trigger internal design 
> investigations, changes in documentation, slides for presentations 
> and so on. Be assured we are reading and even participating.  
> The "Philips_Apps" ID is used for "official" purposes only by 
several 
> members of our technical team.
> 
> Today I would like to pick your brains and get the top-ten charts 
of 
> most wanted features in future LPC2000 devices. I promise this will 
> have an impact on product definition planning if a large number of 
> you participate. 
> 
> By the way, some of the listed features are already in development 
> but we would like to have confirmation we are working on the right 
> things. The majority in the list however is totally open whether 
the 
> features will be implemented in the future or not, your vote 
counts. 
> Last but not least let me tell you that the price tag for these 
> options is very different, e.g. doubling the memory size is a lot 
> more expensive than adding a serial interface. 
> 
> Thank you for the great community in the group and for your help 
> planning upcoming devices. 
> 
> Looking forward to your numerous responses, Robert


Hello philips_apps,

Others have mentioned suggestions which I second:
* An RTC that actually works, i.e. can keep time while the processor 
is in power-down.
* An integrated 1.8V regulator.

And I'd like to add:
* Faster GPIO operation.  It takes way too many clocks, even with a 
pclk divider of 1.
* An integrated reset/brownout circuit.
* PWM: A way to make new PWMMRx values take effect without waiting 
for a PWMMR0 event.  The PWM outputs could then be used to generate 
arbitrary, precisely timed pulses.

Karl Olsen

> 
> Others have mentioned suggestions which I second:
> * An RTC that actually works, i.e. can keep time while the processor 
> is in power-down.
> * An integrated 1.8V regulator.
> 
Of course while many options such as a MAC and different memory
configs are simply a question of different blocks, other options such
as 1.8V regulators and possibly RTC's may be influenced by the
physical characteristics of the semiconductor process used to build
the chip (I note that the process is apparently not a fully static one).

It would be nice however if the chip could be designed to work with a
companion device (possibly one of those allready on the marker) which
would provide voltage regulation, reset, brownout and power down in a
single component solution.

Two options I did not see but would like to and would not require
require building any chips. 

1. A BSDL file. I know you do not have officially have boundary scan,
but you have a JTAG type inteface to the ICE. It would be nice to have
a file with the idcodes, register sizes, etc. So far everything is
compatible with arm documentation, but it would still be nice to have
a bsdl for those parts that are JTAG instead of me having to hack one
together for my software.
2. Open up the programming interface for the flash instead of making
me have to go through your onboard api. I am not sure why programming
the onboard flash should be anymore difficult than any other flash I
have programmed in the past. 



--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...>
wrote:
> Hi all,
> 
> this group has been such a great pool of help for each other and
also 
> for us at Philips. Some of the questions trigger internal design 
> investigations, changes in documentation, slides for presentations 
> and so on. Be assured we are reading and even participating.  
> The "Philips_Apps" ID is used for "official" purposes only by
several 
> members of our technical team.
> 
> Today I would like to pick your brains and get the top-ten charts
of 
> most wanted features in future LPC2000 devices. I promise this will 
> have an impact on product definition planning if a large number of 
> you participate. 
> 
> By the way, some of the listed features are already in development 
> but we would like to have confirmation we are working on the right 
> things. The majority in the list however is totally open whether
the 
> features will be implemented in the future or not, your vote
counts. 

> Last but not least let me tell you that the price tag for these 
> options is very different, e.g. doubling the memory size is a lot 
> more expensive than adding a serial interface. 
> 
> Thank you for the great community in the group and for your help 
> planning upcoming devices. 
> 
> Looking forward to your numerous responses, Robert

At 11:46 PM 6/16/04 +0000, you wrote:
>Today I would like to pick your brains and get the top-ten charts of
>most wanted features in future LPC2000 devices. I promise this will
>have an impact on product definition planning if a large number of
>you participate.

As much memory (both flash and ram) as you can cram in without cost or 
package size increases :)

More A/Ds (8 10bit A/Ds would be a nice start)

A DMA type interface would be nice, particularly for the A/D.  My ideal A/D 
interface would convert the individual channels on a schedule each channel 
with it's own post conversion filtering.  Having a single setup to convert 
all channels at once and store the result is a nice first step though.

More and more flexible timers, especially more match registers.  Ideally 
allow the match registers to work with mutiple timers (I always liked 
Intels queue of match type registers) . Allow them to have external clock 
sources so they can act as counters.  A quadrature interface could be 
useful too.

I have no need for Ethernet MAC or USB

Byteflight and LIN would be nice (There's actually probably enough to do 
LIN already).

On-board EE or FRAM would be nice but the external forms are inexpensive so 
it's not worth much.  (If it's not 'free' it's probably too much).

Smaller packages (fewer pins), and lower cost versions.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 10:38 AM 6/17/04 +0200, you wrote:
>schmitt trigger for all inputs

Good idea.  I have seen micros with the ability to have either Schmitt or 
non-Schmitt inputs (programmable). Anyone know why you want to turn them off?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 12:25 PM 6/17/04 +0000, you wrote:
>2. Open up the programming interface for the flash instead of making
>me have to go through your onboard api. I am not sure why programming
>the onboard flash should be anymore difficult than any other flash I
>have programmed in the past.

We'll have to disagree on this one.  I want Philips to keep these details 
close to themselves.  The public interface encapsulates the details nicely, 
is not difficult to use and should remain the same as the underlying 
algorithm changes.  It's also less difficult than most flash programming 
interfaces I've had to deal with (no finicity timing to get precisely right).

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 11:24 AM 6/17/04 +0000, you wrote:
>It would be nice however if the chip could be designed to work with a
>companion device (possibly one of those allready on the marker) which
>would provide voltage regulation, reset, brownout and power down in a
>single component solution.

Add cheap and available in relatively small quantities (100's) and you got 
my vote.


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

On Jun 17, 2004, at 3:54 AM, Karl Olsen wrote:

> Others have mentioned suggestions which I second:
> * An RTC that actually works, i.e. can keep time while the processor
> is in power-down.
> * An integrated 1.8V regulator.
>
> And I'd like to add:
> * Faster GPIO operation.  It takes way too many clocks, even with a
> pclk divider of 1.
> * An integrated reset/brownout circuit.
>

I would highly second these. Along with my own addition of USB!

The other thing that would be really nice is to not have the primary 
JTAG/trace mode use so many pins! Maybe control the trace function with 
another pin state on reset? Or enable the trace mode to be turned off 
at boot.

Shannon

> Oh oh oh ! !
> 
> I forgot THE most important thing of all kind !  :D
> 
> an LCD controller !!!
> 
> I know Philips makes them already but having them inside and being able to
> drive for instance a 640x480 panel maybe even with colour or monochrome
> would be some of the most awsome thing ... we use Samsung S3BOX44 arm with a
> mean lcd controller but could philips come up with something similar that
> would simply be perfect.

If we're going to say 'LCD controller', let's be very clear to differentiate
between 'raw glass' and high level frambuffer 'LCD controllers'.  I'm still
having flashbacks to ATMELs presentation last week where a dozen different
parts said they had 'LCD controllers' on them, and they all means something
different by it.  You sort of had to go by context--AVRs used it to mean 
'raw glass' while the ARM9 stuff generally meant framebuffer style.  So,
what should I assume for the ARM7 parts in the middle? ;)

Personally, I have little use for 'raw glass' controllers and I prefer the
framebuffer driver type.  

Cheers,
David

Hi,

> It would be nice however if the chip could be designed to work with a
> companion device (possibly one of those allready on the marker) which
> would provide voltage regulation, reset, brownout and power down in a
> single component solution.

I'm about to use TI's TPS70751.
It's intended for DSP. By the time you add up the functions
it does for you, it's much cheaper that way.
It has :

-    Dual 1.8 / 3.3 V output
-    Selectable Power Up sequencing
-    250 mA / 125 mA on Regs
-    Open drain POR with 120 mS delay
-    Open drain Power Good on Reg 1
-    Low noise : 65 uV w/o Bypass cap
-    Quick output cap discharge
-    2 Manual Reset inputs
-    Under Voltage Lockout
-    Thermal shutdown

That seems like a good choice to me, just has the ext WDT
missing.....

-- Kris

At 10:10 AM 6/17/04 -0400, you wrote:
>Byteflight and LIN would be nice (There's actually probably enough to do
>LIN already).

I said Byteflight, I meant Flexray (Flexray is really it's successor and 
makes more sense).  I don't know what I was think about when I wrote that :)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

In which markets do you expect LIN and Flexray to be valuable ?
Only automotive ?

René


--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 10:10 AM 6/17/04 -0400, you wrote:
> >Byteflight and LIN would be nice (There's actually probably enough 
to do
> >LIN already).
> 
> I said Byteflight, I meant Flexray (Flexray is really it's 
successor and 
> makes more sense).  I don't know what I was think about when I 
wrote that :)
>

Hi Robert

Your team could look at the I/O system of the PICF877. It is superb in 
it's choice of features. This chip was so well featured that microchip 
did a general purpose 16 bit processor (18F452) that used exactly the 
same I/O structure, and even made it pin compatable. It has:

    RTC with 32Khz Xtal driver and interrupt capable of waking from sleep
    SPI, I2C Serial etc
    A/D PWM
    Interupt on change inputs - these are VERY usefull.
    Abilility to sleep with almost no power, but wake up when anything
    happens.

I have built a 25 microamp data logger with this device.

What neither of these chip have of course is the ARM core and 32 bit 
peripherals etc which is why i have migrated to Philips

I am currently designing a system with a LPC2106 and a PICF877 - using 
the 877 as an I/O processor for the LPC2106.

Owen Mooney

Hi Owen,

we did look at the PIC12C through PIC18C and generated the LPC900 family. 
http://www.semiconductors.philips.com/selectionguides/tables/45995.html

If you want to have a look at the LPC935 and compare it with the PIC
you will find quite some competitive features also on the Philips
8-bit device. In particular the pricing combined with analog features,
Real-Time-Clock component ...

http://www.semiconductors.philips.com/pip/P89LPC935FDH.html

or a family overview here:
http://www.semiconductors.philips.com/markets/mms/products/microcontrollers/key_solutions/80c51/index.html#lpc900

This is a different ball game and you mentioned it yourself, the PIC
and the LPC900 are great I/O processors, the ARM architecture is not
optimized for I/O handling (although it is SO MUCH BETTER than DSPs).
It is optimized for data throughput at low power.

You combination preferably with a LPC900 device instead of the PIC ;-)
is totally in line of what we are seeing. A faster high performance
CPU for the math, control, algorithm, what ever you want to call it
and a small I/O slave processor that can stay alife with very low power. 

Regards, Robert

--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> Hi Robert
> 
> Your team could look at the I/O system of the PICF877. It is superb in 
> it's choice of features. This chip was so well featured that microchip 
> did a general purpose 16 bit processor (18F452) that used exactly the 
> same I/O structure, and even made it pin compatable. It has:
> 
>     RTC with 32Khz Xtal driver and interrupt capable of waking from
sleep

>     SPI, I2C Serial etc
>     A/D PWM
>     Interupt on change inputs - these are VERY usefull.
>     Abilility to sleep with almost no power, but wake up when anything
>     happens.
> 
> I have built a 25 microamp data logger with this device.
> 
> What neither of these chip have of course is the ARM core and 32 bit 
> peripherals etc which is why i have migrated to Philips
> 
> I am currently designing a system with a LPC2106 and a PICF877 - using 
> the 877 as an I/O processor for the LPC2106.
> 
> Owen Mooney

My suggestion:

On low pin count devices, should you ever revisit the concept of a
"secondary JTAG port," reserve a pin that selects the JTAG port at
reset.  Alternatively, make the port with the ETM module the secondary
port, since this is the one that's more difficult to fit into most
designs.  Enabling (what usually amounts to) the main JTAG interface in
software is too fragile for such a debug mechanism.

I realize that subtle debug improvements are hard to sell.  But the
usefulness of the 210X JTAG is really diminished by the way it is
implemented, in my opinion.

How about a chip with less flash, but more sram. Keep enough onboard
flash read from a serial flash device to load the sram. Or maybe drop
the flash altogether and just automatically boot from a flash device
that implements SPI or I2C.

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...>
wrote:
> Hi all,
> 
> this group has been such a great pool of help for each other and
also 
> for us at Philips. Some of the questions trigger internal design 
> investigations, changes in documentation, slides for presentations 
> and so on. Be assured we are reading and even participating.  
> The "Philips_Apps" ID is used for "official" purposes only by
several 
> members of our technical team.
> 
> Today I would like to pick your brains and get the top-ten charts
of 
> most wanted features in future LPC2000 devices. I promise this will 
> have an impact on product definition planning if a large number of 
> you participate. 
> 
> By the way, some of the listed features are already in development 
> but we would like to have confirmation we are working on the right 
> things. The majority in the list however is totally open whether
the 
> features will be implemented in the future or not, your vote
counts. 

> Last but not least let me tell you that the price tag for these 
> options is very different, e.g. doubling the memory size is a lot 
> more expensive than adding a serial interface. 
> 
> Thank you for the great community in the group and for your help 
> planning upcoming devices. 
> 
> Looking forward to your numerous responses, Robert

At 10:04 PM 6/17/04 +0000, you wrote:
>In which markets do you expect LIN and Flexray to be valuable ?
>Only automotive ?

Automotive is certainly their origin but I do expect to see other 
uses.  Flexray I would expect to enter certain industrial markets just as 
CAN did.  The question there is how big a niche it can find when compared 
to existing CAN implementations and various other fieldbuses.

CAN is being adopted in the industrial electric vehicle market (it's 
actually being used for some drive-by-wire applications), Flexray would 
actually be a better fit there but it will take some time to grow into it.

LIN I see being used (at least the signalling layer) just about everywhere 
that needs a cheap 1-wire serial bus.  I'm working on some stuff that would 
make use of LIN, whether it will ever see the light of day is still open to 
question at the moment but the bus makes sense in the application.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

I used the TPS70851PWP in my design. It has similar specs.

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi,
> 
> > It would be nice however if the chip could be designed to work
with a
> > companion device (possibly one of those allready on the marker)
which
> > would provide voltage regulation, reset, brownout and power down
in a

> > single component solution.
> 
> I'm about to use TI's TPS70751.
> It's intended for DSP. By the time you add up the functions
> it does for you, it's much cheaper that way.
> It has :
> 
> -    Dual 1.8 / 3.3 V output
> -    Selectable Power Up sequencing
> -    250 mA / 125 mA on Regs
> -    Open drain POR with 120 mS delay
> -    Open drain Power Good on Reg 1
> -    Low noise : 65 uV w/o Bypass cap
> -    Quick output cap discharge
> -    2 Manual Reset inputs
> -    Under Voltage Lockout
> -    Thermal shutdown
> 
> That seems like a good choice to me, just has the ext WDT
> missing.....
> 
> -- Kris

On Fri, Jun 18, 2004 at 03:12:32AM -0000, javaguy11111 wrote:
> How about a chip with less flash, but more sram. Keep enough onboard
> flash read from a serial flash device to load the sram. Or maybe drop
> the flash altogether and just automatically boot from a flash device
> that implements SPI or I2C.

SRAM - static RAM - is expensive - at least 6 times more space is needed as
for flash. I think this is the reason for the little RAM on available uC's.
But DRAM is as small as Flash - I dont know why we see no DRAM in
controllers. The additional power consumption (for refresh) is little
higher; static operation is only required for deep sleep mode, probably
process reasons?

        Matthias

On Thu, Jun 17, 2004 at 09:50:33PM -0400, James Dabbs wrote:
> On low pin count devices, should you ever revisit the concept of a
> "secondary JTAG port," reserve a pin that selects the JTAG port at
> reset.  Alternatively, make the port with the ETM module the secondary
> port, since this is the one that's more difficult to fit into most
> designs.  Enabling (what usually amounts to) the main JTAG interface in
> software is too fragile for such a debug mechanism.

Why does it need to be a JTAG port - with no possibility for boundary scans
(on a controller you can use firmware to do the scan) the JTAG port can
replaced by a single pin.

M.

--- In lpc2000@yahoogroups.com, "javaguy11111" <javaguy11111@y...> wrote:
> How about a chip with less flash, but more sram. Keep enough onboard
> flash read from a serial flash device 

Used this sort of setup on AD2105 devices, but the number is a
coincedence, they are DSP's. It is a good scheme allthougth the RAM
requires more chip area than flash. Even so, with todays densities I
would not imagine it is much of a problem.

I think the chips that use this method don't use a bootloader but a
simple state machine to clock in the contents from an SPI device.

As already mentioned, the nice thing about LIN is the simple 1-wire 
signal layer - this is really made for the smallest controllers with 
limited horsepower (makes you wonder why we talk about it in this 
group :-)

In order to make the protocol more interchangeable with "embedded 
networks" we came up with MicroMessaging – one could say a subset of 
CANopen. So a MicroMessaging network could use LIN (or other lowest 
cost serial channels like I2C), but could also be interfaced to 
CANopen – providing a transparent network infrastructure across 
serial network technologies.

For more info see www.MicroMessaging.com and www.MicroCANopen.com 

Olaf
Tutor at ESAcademy
www.esacademy.com

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 10:04 PM 6/17/04 +0000, you wrote:
> >In which markets do you expect LIN and Flexray to be valuable ?
> >Only automotive ?
> 
> Automotive is certainly their origin but I do expect to see other 
> uses.  Flexray I would expect to enter certain industrial markets 
just as 
> CAN did.  The question there is how big a niche it can find when 
compared 
> to existing CAN implementations and various other fieldbuses.
> 
> CAN is being adopted in the industrial electric vehicle market 
(it's 
> actually being used for some drive-by-wire applications), Flexray 
would 
> actually be a better fit there but it will take some time to grow 
into it.
> 
> LIN I see being used (at least the signalling layer) just about 
everywhere 
> that needs a cheap 1-wire serial bus.  I'm working on some stuff 
that would 
> make use of LIN, whether it will ever see the light of day is still 
open to 
> question at the moment but the bus makes sense in the application.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

>    From: "philips_apps" <philips_apps@...>

> Today I would like to pick your brains and get the top-ten charts
> of most wanted features in future LPC2000 devices. I promise this
> will have an impact on product definition planning if a large
> number of you participate.

Since we can easily fit our web server with CGI and ASP in a 
2106 with serial EEPROM for page storage, Ethernet would be 
great. A proper RTC would be nice, but there are plenty of I2C 
solutions. Most of our industrial clients want Ethernet or USB. 
However, for USB the FTDI devices are fairly cheap and avoid all 
the hassle of writing PC device drivers. If you provide USB, 
please make it that easy.

But above all, make the GPIO faster and document the interaction 
between LDR/STR instructions, the VPB and the MAM. As a compiler 
vendor, I'm spending too much time writing app notes that should 
be in the user manual. As an application writer, I'm reinventing 
the wheel far too often. This wasted time increases the cost of 
2xxx development for us and our clients.

Again for fast GPIO use, when we use several GPIO pins as a bus 
we have to go through contortions. If there were OPDATA and 
OPMASK registers life would be simple, especially if writing to 
the OPMASK register also set the direction register - we spend 
too much time doing read/modify/writes and the three cycle LDR 
plus VPB overhead kills us.

Since someone at Philips has already written test code, it 
should easy to provide a simple example (10-30 lines) in the 
user manual for each peripheral. Just the basics, no interrupts, 
just simple initialisation and use IN ASSEMBLER. You've got that 
lovely I2C hardware, but the referred example is for an 8051 and 
porting our bit-banged master code took less than hour, so we 
didn't bother. Old-timers fondly remember the days when monitor 
listings were included in CPU data sheets.

You can always put standard example drivers on your web site. 
When you do this, please make sure that they work - debugging 
the Samsung S3C4510B Ethernet driver example still haunts me!

Have a look at the Atmel PDC as an alternative to full-blown DMA.

But, despite all this it's a great series. The bad news for 
Philips will only be that as far as we are concerned the 8051 is 
dead. When an ARM is as good as an 8051 at bit-banging that will 
be truly something.

Stephen

--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

At 12:33 PM 6/18/04 +0000, you wrote:
>As already mentioned, the nice thing about LIN is the simple 1-wire
>signal layer - this is really made for the smallest controllers with
>limited horsepower (makes you wonder why we talk about it in this
>group :-)

:)
Well, I'm thinking  of it using ARMs mostly as master devices using LIN 
slaves for remote sensor/actuator.  Although I do have a case where 
reducing the number of connections is a big plus and the amount of 
communication is small so....

>In order to make the protocol more interchangeable with "embedded
>networks" we came up with MicroMessaging ­ one could say a subset of
>CANopen.

Have you read though the LIN 2.0 spec?  I just recently got it.  I had 
previously been through the 1.3 spec at an earlier job.  They have updated 
the higher levels in particular.  The LIN spec very nearly weaves itself 
into the application layer.  I can see where that would be quite useful 
when you are integrating multiple third party slaves.  With proper tools 
the complete network interface would conceivably be built in a matter of 
minutes.


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

This thread has become something of a wish list and although I would 
probably add my 3 wishes to the list I guess there is a question we 
could all ask ourselves. What would make me actually consider anything 
other than a 2000 for a particular project? The 2000 line has to be a 
competitive line for Philips, it does not matter if it were a great chip 
or a throwback (take your pic), as long as it was good business.

Anyway, I could answer that question very quickly, it would be Ethernet 
and USB (along with DMA). These are two devices which if implemented 
externally would complicate what could of been a clean solution. At 
present I must either choose something like Atmel or OKI, or else an 
external bus 2000 coupled to these peripherals. Personally, I'd like to 
stick to the 2000 line and what better incentive would there be then if 
Uncle Phil could cook up some hot chips served along with the Mayonnaise 
(Dutch thing).

Something else that whilst it does not seem as important does severely 
curtail the use of the 2000 as a more general-purpose micro. This has 
been brought up before and it is the I/O speed. Yeah, despite all those 
yummy peripherals we still need to bit-bang sometimes, the faster the 
better. This would mean little if the 2000 did not have an efficient 
manner in which to execute these operations either and this has been 
covered also.

When it comes to regulators and brownout reset circuits it is always 
advantageous to have these incorporated on the device. But failing that 
why can't Philips come out with a nice little dual regulator perhaps in 
combo with the reset circuit. The use of LM117s in SOT-22(many)3 packs 
is seemingly out of step with the low-power and size of the 2000. Yes, 
TI have some nice regs which I have used, yet Philips can and really 
should provide what amounts to companion chips that form part of the 
product family.

When it comes to more UARTs, ADCs, etc., well, where do you draw the 
line? I know I could use more UARTs but there are ways around this like 
chaining multiple devices together over the SPI or I2C bus. But Uncle 
Phil mentioned I2S and that caught my attention. I'd like to do audio 
work with an ARM and what better way than to have a simple connection to 
what are typically DSP peripherals.

As for the rest, well;

* Boundary Scan
    Don't need it

* Combo Flash and RAM
    Maybe less rather than more because that would also mean cheaper and 
so I could replace my little micros as well with an LPC2002??!!!

* EEPROM
    Would be nice but I can do this with external I2C devices easily. 
Maybe the internal Flash could have a couple of small independent pages 
perhaps?

* SDRAM, LCD, 80MHz
    This is not the market for the 2000 now although it may become that. 
There are plenty of manufacturers out there doing this now with ARM.

* Low and micro-power

    This is always hard to define properly as to what is acceptable. 
Sometimes it is fine if the whole chip is halted and oscillators stopped 
as long as it can be woken up with a GPIO input change. Other times we 
want to keep some power hungry peripheral active (Uart, Ethernet) and 
have the unused sections sleep. Others want 32KHz RTC operation. Having 
an on-board RC oscillator is prepatory to any low-power (and watchdog) 
considerations. Stability, at least in the short-term vs accuracy is 
more important in this regard. The RC oscillator can be calibrated 
against the cystal allowing the crystal oscillator to be shut-down so 
that timing can be maintained for some peripherals. Good or bad, at 
least an RC watchdog circuit can wake-up the rest of the chip.

my2cents

--
Peter Jakacki

Thanks for that feedback Robert. If I can suggest 1 PIC idea, it is the interrupt on change. The level trigged interupts on the LPC21xx don't map well into typical microcontroller circuits. Edge triggered are much better. My suggestion is 2 registers for edge triggered interrupts, giving each of the 32 I/O lines 4 options for interrupts:- none, rising edge, falling edge, either edge. 

Regards

Owen

Message: 9
   Date: Thu, 17 Jun 2004 23:10:46 -0000
   From: "philips_apps" 
Subject: Re: New Poll started with Wish-List for future devices

Hi Owen,

we did look at the PIC12C through PIC18C and generated the LPC900 family. 
http://www.semiconductors.philips.com/selectionguides/tables/45995.html

If you want to have a look at the LPC935 and compare it with the PIC
you will find quite some competitive features also on the Philips
8-bit device. In particular the pricing combined with analog features,
Real-Time-Clock component ...

http://www.semiconductors.philips.com/pip/P89LPC935FDH.html

or a family overview here:
http://www.semiconductors.philips.com/markets/mms/products/microcontrollers/key_solutions/80c51/index.html#lpc900

This is a different ball game and you mentioned it yourself, the PIC
and the LPC900 are great I/O processors, the ARM architecture is not
optimized for I/O handling (although it is SO MUCH BETTER than DSPs).
It is optimized for data throughput at low power.

You combination preferably with a LPC900 device instead of the PIC 
is totally in line of what we are seeing. A faster high performance
CPU for the math, control, algorithm, what ever you want to call it
and a small I/O slave processor that can stay alife with very low power. 

Regards, Robert

--- In lpc2000@yahoogroups.com, Owen Mooney  wrote:

sleep

--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> 
That's nice to see that Philips will improve the LPC21xx series, but 
only hope that it will be soon because Atmel will release the 
AT91SAM7S64 around August, with most of features from this whishlist:

FYI:

Clock Speed (MHz)* 	 55 (Max clock speed @ +85°C)
SRAM (Bytes)		 16K
Flash (Bytes)		 64K
Enhanced USART (PDC)	 2
SPI (PDC)		 1
TWI			 1
SSC (PDC)		 1
USB Device (Full Speed)	 1
16-bit Timers		 3
PWM Controller		 4
Period Inteval Timer	 1
Watchdog Timer		 1
RTC / RTT		 -/1
10-bit ADC Channel (PDC) 8
Power-On Reset		 1
Brown Out Detection	 1
On-chip RC Oscillator	 1
High Current Pads	 4
I/O Pins		 32
Power Supply (V)	 3.0-3.6 (1.8v on-chip regulator)
Package			 QFP64

Glossary:
RTC/RTT: Real Time Clock / Real Time Timer
Enhanced USART: supports RS485, ISO7816, IrDA and modem control lines.
TWI: Two Wire Interface, interconnects components on a two-wire bus 
(I2C compatible).
SSC: Serial Synchronous Controller, supports many serial synchronous 
communications protocols used in audio and telecom applications such 
as I2S, short or long frame sync.
16-bit Timers: Capture/Compare, Waveform generation and PWM modes.
PDC: Peripheral Data Controller (DMA), transfers data between on-chip 
USART, SSC, SPI, ADC and the on and off-chip memories without CPU 
intervention.

Bye

> That's nice to see that Philips will improve the LPC21xx series, 
but 
> only hope that it will be soon because Atmel will release the 
> AT91SAM7S64 around August, with most of features from this 
whishlist:
> 
<snip>

That's nice, but the Sharp chip (LH79525) blows it out of the water.

ARM720T core
77.4mhz
16k sram
10/100 ethernet mac
full speed usb 2.0
ten input 10 bit A/D
Four DMA channels
SDRAM controller
three 16C550 uarts
BUFFERED SPI port DMA supported (woo hoo!, finally) 
I2C
on chip 3.3V to 1.8 volt regulator
three 16 bit timers with PWM
real time 32khz clock
external bus
color lcd controller

Darn it, they forgot the kitchen sink....

On Jun 21, 2004, at 9:12 AM, skykotech wrote:

> That's nice, but the Sharp chip (LH79525) blows it out of the water.
>
> ARM720T core
> 77.4mhz
> 16k sram
> 10/100 ethernet mac
> full speed usb 2.0
> ten input 10 bit A/D
> Four DMA channels
> SDRAM controller
> three 16C550 uarts
> BUFFERED SPI port DMA supported (woo hoo!, finally)
> I2C
> on chip 3.3V to 1.8 volt regulator
> three 16 bit timers with PWM
> real time 32khz clock
> external bus
> color lcd controller
>
> Darn it, they forgot the kitchen sink....
>

Yes, it has lots of stuff (I worked with the LH79520 before and it was 
quite nice). But it also comes in a 176 pin package, has no flash and 
costs around $12/10k. Different beast.

Don't get me wrong - I love all these features, just small and cheap 
are great things!

Shannon