ARM7 with longevity of supply

Tom Lucas wrote:
> "PeteS" <peter.smith8380@ntlworld.com> wrote in message
> news:CTJ6h.39441$Ib.22108@newsfe1-gui.ntli.net...
> > Tom Lucas wrote:
> >> I've narrowed down my choices using the following criteria:
> >> * Must have full IAR compiler support including headers, flashloaders
> >> and examples.
> >> * Must have an external bus to connect to 8bit peripherals and also
> >> RAM/ROM.
> >> * Must have JTAG interface.
> >> * Must have minimum 16bit timers, preferably 32 bit.
> >> * Must have watchdog timer.
> >> * Must not be in a BGA package.
> >>
> >> I believe this narrows the selection down to the following parts:
> >> Freescale MAC7111
> >> Phillips LPC2292/2294
> >> ST Electronics STR710/750 (non-BGA flavours)

Who am I to argue with your requirements, but you might reconsider the
need for an 8 bit bus.  These days most I/O is done directly from the
MCU or if expansion is needed, using SPI or I2C.  If you tell us what
you need on the other end of the 8 bit bus maybe we can help you see
how easy it is to use one of the serial interfaces.

This is an issue because adding a data and address bus to an MCU
greatly increases the pin count and package size and therefore cost.


> > Seems something in the TI TMS470 series might fit the bill, if you're
> > still looking at stuff. I'm designing a new product around one of
> > these for various reasons, and TI has given me assurances they are
> > going to be produced for at least the next 6 years (that's as far as
> > the roadmap goes, apparently).
>
> Someone warned me off the TI parts because the datasheet is inaccurate
> apparently and they won't talk to you unless you are tier 1 automaotive.
> Something about high impedance not really being high impedance or
> something. However, this is purely anecdotal and not something I have
> personal experience of.

I think you will find that all MCUs these days have errata.  I know the
Atmel parts include it in the data sheet so you can review them
yourself to see if they are a problem.  I also don't think you will
find 5 years to be a problem for a product lifetime since nearly all
the ARM MCUs are relatively new and in high demand.

You can review some information on a large number of ARM MCUs at
www.gnuarm.com.  Go to the resources page and scroll down to the ARM
chips section where you will find an ARM device comparison chart link.
I don't claim the information is complete or accurate, but it is a good
start.

One observation, if you want lower power chips, Atmel and NXP (Philips)
are about neck and neck with roughly half the power consumption of the
other vendors.  These parts will actually run at lower power than many
8 bit cores when you run them at the same speed.  This is due to the
smaller process geometries.

Luminary Micro uses the Cortex-M3 core which is the latest from ARM and
is specifically designed for embedded work.  They wanted to get their
product out the door quickly, so they are using a 250 nm process and
their power is a bit higher than the others, but they have other parts
coming out in the spring.  The Cortex-M3 core has some improvements in
code density, processing speed, exception handling and ARM has
standardized some of the peripherals which means you can port between
different chip makers more easily.

You might also ask about any of these chips in comp.sys.arm and in the
Yahoo groups for the different processor types, AT91SAM, LPC2000, STR7,
ARMSTR, TMS470_ARM, ADuC_ARM, arm-user, ARM_Microcontroller,
OKI-ARM-mcus, arm32bit, stellaris_lm, Cortex-M3.

"Tom Lucas" <news@REMOVE_auto_THIS_flame_TO_REPLY.clara.co.uk> writes:

>
>> Re external bus, this is available on most device families. But don't
>> forget you may be able to bit-bang your old peripherals just as
>> easily.
>
> My life is hard enough already ;-) 

 :) Of course it all depends on your requirements. But take for
example something like a character module LCD. I usually find it
*easier* to drive it completely in software, rather than worry about
address decoding, bus type, clock edge polarities etc, at hardware
design time! An ARM7 is so fast compared to the old 8 bitters, you can
do a lot of things like this. Same goes for I2C real time clocks &
memories. And once you have the module written you can easily transfer
it to a new chip.

-- 

John Devereux

"rickman" <gnuarm@gmail.com> wrote in message 
news:1163696010.261458.83880@m7g2000cwm.googlegroups.com...
> Tom Lucas wrote:
>> "PeteS" <peter.smith8380@ntlworld.com> wrote in message
>> news:CTJ6h.39441$Ib.22108@newsfe1-gui.ntli.net...
>> > Tom Lucas wrote:
>> >> I've narrowed down my choices using the following criteria:
>> >> * Must have full IAR compiler support including headers, 
>> >> flashloaders
>> >> and examples.
>> >> * Must have an external bus to connect to 8bit peripherals and 
>> >> also
>> >> RAM/ROM.
>> >> * Must have JTAG interface.
>> >> * Must have minimum 16bit timers, preferably 32 bit.
>> >> * Must have watchdog timer.
>> >> * Must not be in a BGA package.
>> >>
>> >> I believe this narrows the selection down to the following parts:
>> >> Freescale MAC7111
>> >> Phillips LPC2292/2294
>> >> ST Electronics STR710/750 (non-BGA flavours)
>
> Who am I to argue with your requirements, but you might reconsider the
> need for an 8 bit bus.  These days most I/O is done directly from the
> MCU or if expansion is needed, using SPI or I2C.  If you tell us what
> you need on the other end of the 8 bit bus maybe we can help you see
> how easy it is to use one of the serial interfaces.
>
> This is an issue because adding a data and address bus to an MCU
> greatly increases the pin count and package size and therefore cost.

You are right in what you say and realistically I could probably do away 
with a lot of the latches and flip-flops that expect 8 bit busses 
(probably into an FPGA). However, I am only intending to replace the 
processor area of an existing and working design and don't want too much 
upheaval. It's less than ideal I know but gettign management to move 
away from 80188 will be hard enough without having to redo the rest of 
the system.

>> > Seems something in the TI TMS470 series might fit the bill, if 
>> > you're
>> > still looking at stuff. I'm designing a new product around one of
>> > these for various reasons, and TI has given me assurances they are
>> > going to be produced for at least the next 6 years (that's as far 
>> > as
>> > the roadmap goes, apparently).
>>
>> Someone warned me off the TI parts because the datasheet is 
>> inaccurate
>> apparently and they won't talk to you unless you are tier 1 
>> automaotive.
>> Something about high impedance not really being high impedance or
>> something. However, this is purely anecdotal and not something I have
>> personal experience of.
>
> I think you will find that all MCUs these days have errata.  I know 
> the
> Atmel parts include it in the data sheet so you can review them
> yourself to see if they are a problem.  I also don't think you will
> find 5 years to be a problem for a product lifetime since nearly all
> the ARM MCUs are relatively new and in high demand.

I think a lot of the longevity depends on large (probably automotive) 
manufacturers adopting the microcontroller in question.

> You can review some information on a large number of ARM MCUs at
> www.gnuarm.com.  Go to the resources page and scroll down to the ARM
> chips section where you will find an ARM device comparison chart link.
> I don't claim the information is complete or accurate, but it is a 
> good
> start.

Very good link. Someone else posted it earlier but thanks anyway.

> One observation, if you want lower power chips, Atmel and NXP 
> (Philips)
> are about neck and neck with roughly half the power consumption of the
> other vendors.  These parts will actually run at lower power than many
> 8 bit cores when you run them at the same speed.  This is due to the
> smaller process geometries.

I have oodles of power available so that is one restriction I can be 
free of.

> Luminary Micro uses the Cortex-M3 core which is the latest from ARM 
> and
> is specifically designed for embedded work.  They wanted to get their
> product out the door quickly, so they are using a 250 nm process and
> their power is a bit higher than the others, but they have other parts
> coming out in the spring.  The Cortex-M3 core has some improvements in
> code density, processing speed, exception handling and ARM has
> standardized some of the peripherals which means you can port between
> different chip makers more easily.
>
> You might also ask about any of these chips in comp.sys.arm and in the
> Yahoo groups for the different processor types, AT91SAM, LPC2000, 
> STR7,
> ARMSTR, TMS470_ARM, ADuC_ARM, arm-user, ARM_Microcontroller,
> OKI-ARM-mcus, arm32bit, stellaris_lm, Cortex-M3.
> 

Tom Lucas wrote:

> "rickman" <gnuarm@gmail.com> wrote in message 
>>Who am I to argue with your requirements, but you might reconsider the
>>need for an 8 bit bus.  These days most I/O is done directly from the
>>MCU or if expansion is needed, using SPI or I2C.  If you tell us what
>>you need on the other end of the 8 bit bus maybe we can help you see
>>how easy it is to use one of the serial interfaces.
>>
>>This is an issue because adding a data and address bus to an MCU
>>greatly increases the pin count and package size and therefore cost.
> 
> 
> You are right in what you say and realistically I could probably do away 
> with a lot of the latches and flip-flops that expect 8 bit busses 
> (probably into an FPGA). However, I am only intending to replace the 
> processor area of an existing and working design and don't want too much 
> upheaval. It's less than ideal I know but gettign management to move 
> away from 80188 will be hard enough without having to redo the rest of 
> the system.

In this situation you could look at a CPLD that does ARM_SPI or ARM_SSC 
to legacy-parallel bus, for the external latch-sea.
SPI speeds can match the MHz region 188BUS IO, and you open up more 
choices in the Processor front, plus save a lot of PCB traces and EMC
headaches  - you can even optoisolate the SPI link.

-jg

Tom Lucas wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> > Who am I to argue with your requirements, but you might reconsider the
> > need for an 8 bit bus.  These days most I/O is done directly from the
> > MCU or if expansion is needed, using SPI or I2C.  If you tell us what
> > you need on the other end of the 8 bit bus maybe we can help you see
> > how easy it is to use one of the serial interfaces.
> >
> > This is an issue because adding a data and address bus to an MCU
> > greatly increases the pin count and package size and therefore cost.
>
> You are right in what you say and realistically I could probably do away
> with a lot of the latches and flip-flops that expect 8 bit busses
> (probably into an FPGA). However, I am only intending to replace the
> processor area of an existing and working design and don't want too much
> upheaval. It's less than ideal I know but gettign management to move
> away from 80188 will be hard enough without having to redo the rest of
> the system.

If you are using latches and FFs, you likely can find ways to roll that
into the MCU if you think about it a bit.

Cypress has been talking to me about their planned ARM parts that will
have the PSOC peripherals.  That will be an amazing combination, almost
as good as an MCU and a CPLD!


> > I also don't think you will
> > find 5 years to be a problem for a product lifetime since nearly all
> > the ARM MCUs are relatively new and in high demand.
>
> I think a lot of the longevity depends on large (probably automotive)
> manufacturers adopting the microcontroller in question.

I think you will find that most ARM makers are shipping plenty of parts
and you can expect the quantities to continue for many years.  With
several big semiconductor players adopting the ARM as their primary MCU
to market, this has push the architecture to the forefront in a way
that will be even stronger than the 8051 MCU.  The chips being made
today are very good with very low power and high degrees of efficiency
and robustness so they will still be in products for many years.
Certainly if you go with one of the two big players, Atmel and NXP, you
will be able to buy these chips for many years.  I don't think they
need an automotive partner.  In fact, the automotive market likely will
move on to newer chips since with their volumes a savings of just a few
cents justifies changing to a different part.


> > One observation, if you want lower power chips, Atmel and NXP
> > (Philips)
> > are about neck and neck with roughly half the power consumption of the
> > other vendors.  These parts will actually run at lower power than many
> > 8 bit cores when you run them at the same speed.  This is due to the
> > smaller process geometries.
>
> I have oodles of power available so that is one restriction I can be
> free of.

Yes, some apps don't care about power consumption, but there can also
be power dissapation issues, but I expect you don't have that
limitation either.  If you were using the old technology you mentioned,
you will find the new parts to be a lot more size efficient too.

rickman wrote:
> Cypress has been talking to me about their planned ARM parts that will
> have the PSOC peripherals.  That will be an amazing combination, almost
> as good as an MCU and a CPLD!

  Yes, but will you be able to 'get at' the 'CPLD' portion ? - their 
PSoC claimed many things, but was very light on the details, ( I see now 
they claim 'No Code' development!), and they moved to more common 
peripherals on the newer variants.

  AnalogDevices have ARMs with a small 'PLD' in now.

-jg

Jim Granville wrote:
> rickman wrote:
> > Cypress has been talking to me about their planned ARM parts that will
> > have the PSOC peripherals.  That will be an amazing combination, almost
> > as good as an MCU and a CPLD!
>
>   Yes, but will you be able to 'get at' the 'CPLD' portion ? - their
> PSoC claimed many things, but was very light on the details, ( I see now
> they claim 'No Code' development!), and they moved to more common
> peripherals on the newer variants.

I'm not sure what you mean about the newer peripherals.  They all have
the same structure as far as I am aware.  There is one hardware I2C
port, but I think that is because it has some special functions.

>   AnalogDevices have ARMs with a small 'PLD' in now.

Calling the logic in the ADUC7000 a PLD is doing the programmable logic
world a disservice.  I take it you have never looked at this "small
PLD"?  While you can build UARTs, SPI ports, and even more complex
things in the PSOC devices (not to mention the analog functions), I
have not figured out just what I could use the ADUC7000 logic for.

rickman wrote:

> Jim Granville wrote:
> 
>>rickman wrote:
>>
>>>Cypress has been talking to me about their planned ARM parts that will
>>>have the PSOC peripherals.  That will be an amazing combination, almost
>>>as good as an MCU and a CPLD!
>>
>>  Yes, but will you be able to 'get at' the 'CPLD' portion ? - their
>>PSoC claimed many things, but was very light on the details, ( I see now
>>they claim 'No Code' development!), and they moved to more common
>>peripherals on the newer variants.
> 
> 
> I'm not sure what you mean about the newer peripherals.  They all have
> the same structure as far as I am aware.  There is one hardware I2C
> port, but I think that is because it has some special functions.

Yes, it was too complex for their Digtal Blocks! :)

I'm looking at CY8C41123, and I can see ADC 20ksps and DAC, not in their
Analog blocks, but as Std functions, and the Digital Blocks that
are there, make no claims at all about UART/SPI abilities, just
8/16 bit timers/counters. Whoop-de-do, to a sum total of 32 bits - looks 
like any vanilla uC there, even lighter than some with just 4 bytes of 
timers. [no mention of pwm ?]

Yes, I think they can mux to any pin, so I'd call that a TimerBlock + 
better class of MUX.


> 
>>  AnalogDevices have ARMs with a small 'PLD' in now.
> 
> 
> Calling the logic in the ADUC7000 a PLD is doing the programmable logic
> world a disservice.  I take it you have never looked at this "small
> PLD"?  While you can build UARTs, SPI ports, and even more complex
> things in the PSOC devices (not to mention the analog functions), I
> have not figured out just what I could use the ADUC7000 logic for.

you'll see I did call it a small 'PLD'.

In the ADuC702x data, they claim 16ip and 14op, so that's a vanilla 
16V14 pld(PLA), and it can Signal MUX, or start the ADC. Could be 
usefull for feeding multiple freqency sources into a single timer.
ADuC702x timers have more resolution than the PsOC.

-jg

Jim Granville wrote:
> rickman wrote:
>
> > Jim Granville wrote:
> >
> >>rickman wrote:
> >>
> >>>Cypress has been talking to me about their planned ARM parts that will
> >>>have the PSOC peripherals.  That will be an amazing combination, almost
> >>>as good as an MCU and a CPLD!
> >>
> >>  Yes, but will you be able to 'get at' the 'CPLD' portion ? - their
> >>PSoC claimed many things, but was very light on the details, ( I see now
> >>they claim 'No Code' development!), and they moved to more common
> >>peripherals on the newer variants.
> >
> >
> > I'm not sure what you mean about the newer peripherals.  They all have
> > the same structure as far as I am aware.  There is one hardware I2C
> > port, but I think that is because it has some special functions.
>
> Yes, it was too complex for their Digtal Blocks! :)
>
> I'm looking at CY8C41123, and I can see ADC 20ksps and DAC, not in their
> Analog blocks, but as Std functions, and the Digital Blocks that
> are there, make no claims at all about UART/SPI abilities, just
> 8/16 bit timers/counters. Whoop-de-do, to a sum total of 32 bits - looks
> like any vanilla uC there, even lighter than some with just 4 bytes of
> timers. [no mention of pwm ?]
>
> Yes, I think they can mux to any pin, so I'd call that a TimerBlock +
> better class of MUX.

This is not a standard PSOC, it is a "Linear Power PSoC=99 Device" and
is "a cost-reduced version of the CY8C42x23 that targets linear-control
applications."  You make it sound like the part is junk!  Cypress has
always targeted cost sensitive applications and they produce a wide
range of devices to optimize the cost.  This is just another part in a
complex MCU market.

> >>  AnalogDevices have ARMs with a small 'PLD' in now.
> >
> >
> > Calling the logic in the ADUC7000 a PLD is doing the programmable logic
> > world a disservice.  I take it you have never looked at this "small
> > PLD"?  While you can build UARTs, SPI ports, and even more complex
> > things in the PSOC devices (not to mention the analog functions), I
> > have not figured out just what I could use the ADUC7000 logic for.
>
> you'll see I did call it a small 'PLD'.

Yes, and I don't think you realize that I think that is an
overstatement.  It is so primative that I don't know how it could be of
much use.  I thought it was a great idea until I read about it and
found it has very little real value.


> In the ADuC702x data, they claim 16ip and 14op, so that's a vanilla
> 16V14 pld(PLA), and it can Signal MUX, or start the ADC. Could be
> usefull for feeding multiple freqency sources into a single timer.
> ADuC702x timers have more resolution than the PsOC.

No, it is *nothing* like a 16V14.  Read the description of what logic
it contains and you will be surprised too.  Yes, you might be able to
use it as some 2 to 1 muxes.  Whoo hoo!

I don't get your position.  You think the PSOC devices are not of much
value and the PLD in the ADUC is a valuable thing?

rickman wrote:
> 
> I don't get your position.  You think the PSOC devices are not of much
> value and the PLD in the ADUC is a valuable thing?

  No, I think the PSoC is somewhat overhyped, and I observed that
the hyped elements have been morphing 'simpler', over time, and
more STD HW blocks are being added (not the opposite trend)
and gave a recent Cypress PSoC example.

  I like the High voltage features of the PSoC device I was quoting.

  All I said of the ADUC was that it has a "small 'PLD'" - just two words.

  I will look at the ARM PSoC, when released, as one big drawback of the 
present ones, is the orphan core.

  My overall opinion of mixing Microcontrollers and Logic on one "System 
on a Chip" is luke-warm.

  The problem is matching the respective uC:CPLD powers, and tools.
Anyone remember Triscend ? - or Atmel's FPslic ?


-jg