>   In this formal environment, how do you handle die revisions by the
> supplier ? - Strictly, that should see a re-cycle, but I am not sure
> that actually gets done :)
>
>   Certainly a migration like AT90S2313 [EOL] to ATtiny2313 should see
> the full re-approval cycle, correct ?
>
> -jg


Yes it does.
The introduction of Lead Free packaging will also mean full reapproval
and the migration from the AT89C51 to the AT89S51 needs it as well.
It shoudl be fairly safe to stay with 5 Volt parts since migration to denser
processes will not happen, but then there will not be price reductions
either.

Process shrinks will continue due to the demand for lower prices.
When the large companies say they are prepared to accept price increases to
keep the parts
in production, then they will be kept in production.
Prices cannot stay the same, since failing to shrink means that you cannot
increase
the output in the same fab/equipment.

I hardly think that is going to happen though.

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Jim Granville wrote:
>> Customer have achieved 16,5 bit resolution on the AVR ADC converter
> 
> 
> ...and sustained that across replacements, temperature, and production ?
> [ and all with a 10 bit result register, that has a 4 bit typ [no max] 
> error band ?! ]
> 
Hi Jim,

Note, he did NOT say 16 bit ACCURATE - 16 bit resolution is easy - but 
do you believe the answers ???

Steve

Nicholas O. Lindan wrote:

> > > There are VERY few uCs with second sources.
>
> My guess is those might be the ones that will still be around in 25
years.

My point is that they're a limited, mediocre pool of parts now and will
be a limited, mediocre pool of parts in 25 years.

>  o Product differentiation;

That's part of it. Another part of it is that if a chip vendor invents
a process or peripheral that's really cool, they'll patent the design
and copyright the implementation. Another vendor who wants to offer
similar functionality at a competitive price point can't duplicate the
existing part without paying licensing fees. They are *forced* to be
incompatible, or at least different (=> not second-source candidate) if
they want to sell any parts.

>  o A belief America can't compete in commodity electronics.

Manufacturing or designing? The evidence points strongly towards the
fact that the only way first-world countries could compete on price
would be by lowering professional incomes to third-world levels. The
only way this could work is if the entire economy was scaled down in
proportion. Not going to happen.

Simple market statistics show that consumers are strongly driven by
retail price. You might argue that a locally made product is better,
lasts longer, or gets whites whiter than white, but the point is moot
if the American DVD player is $100 and the Chinese one is $40.

> > > products. We do not design in a uC unless we have a guaranteed
5-year
> > > buy life on the part.
>
> I have seen that fall flat on it's face.  If the manufacturer goes
> under the contract may be hard to enforce.

True, but I don't think it's likely that Atmel, Philips or NEC are
going to go under in the next five years.

>   I once had an engineer try to sell me a patent: The firm where
>   he once worked still owned the patent; But that was OK, he had an

:)) Let me guess, he had a bridge on offer as a gift with purchase?

> This has happened to me, at one time vanilla P8732's weren't
available

Try designing a device that has to last for 600,000 operations off a
single CR2032 cell and needs to fit into the handle of a rather fat
door key. See how many generic parts there are that can be used in this
application.

In article <1ITHd.2344$r...@newsread3.news.atl.earthlink.net>,
Nicholas O. Lindan <s...@sig.com> writes
>Harvard MBA's: 
>
> o Product differentiation;
> o A belief America can't compete in commodity electronics. 

What has he fact that some foreign country can't compete got to do with
this? :-)

This is an international NG


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Ulf Samuelsson" <u...@NOSPAMatmel.com> wrote

> > Any uP used in cell-phones seems to have a 1-year lifespan
> ATtiny28V is in a cell phone, and was in a cell phone one year ago, and
> in another one previously.
_Two_ Years! Imagine That!

> > Second sourcing is still important in industrial products.
> > A uP without a viable producing second source won't (shouldn't) get
> > designed in.
> You will be severely limited if this is a requirement.
You mean 'You will not choose Atmel', and you are correct.

> > With a 25 year history, the 8051 was the right choice for designs in
> > the 80's.  Will it survive for another 25 years?  Probably, _lots_ of
> > people make it and the chances are some niche manufacturer will be
> > making it the year 2030.  Will the AVR still be around, will Atmel  still
> > be around?

> The main difficulty is in changing compilers, and peripherals.
> Ericsson ported their 512 kB GSM stack from the Z80 to the AVR in a week.

Well, that answers the question of Atmel's long-term viability.

> > Odds on that all-in-ones (A/D, D/A, CAN, USB, I2C...) will be soon
> > gone and replaced with new whizzees with the latest in 3-D graphics,
> > sat-com, 8Mpix vision, T1...
 
> Atmel has product lines with an ASSP strategy, and other product lines with
> a standard product portfolio strategy

"ASPP" strategy and "ASSP" strategy?  That's cool.  I'll remember.

> ... AVR and AT91 are standard product ... AT76 and the AT75 shorter 
> lifetime ... although there are chips where  these product lines 
> decide to adopt a standard approach ... the AT75C140 has been renamed 
> the AT91C140 to make this fact clear ... AT76C713 still has an ASSP 
> part number.

Except on Tuesdays, I imagine.

> > That Nokia designed the AVR9000TMXSW54 into the new cell phone doesn't
> > count for squat.  That Maytag or Bosch designed a PIC16C54 into a
> > washing machine timer does.
> Maybe AVRs in Whirlpool, Electrolux, Invensys washing machines, microwave
> ovens etc. counts as well.

It might, it might (except for Invensys & uWaves).  Only time will tell, 
won't it?  Lets resume discussion in the year 2030, shall we?

"Never explain, never complain".
Never explain: nobody will understand.  Never complain: nobody will care.

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Ulf Samuelsson wrote:
>>>Productivity and maintainability should also be discussed.
>>>If you write code optimimzed for maintainability, you will do good on
>>>an AVR.
>>>On an 8051, you will have a problem with a lot of local variables and
>>>recursion.
>>>You have to be much more careful, I.E: spend more time to do good code
>>>on a 51.
>>>
>>
>>Something else to consider is the life expectancy of the particular AVR
>>one chooses to use. Some models only seem to survive for a couple of
>>years in the marketplace before being obsoleted.
>>The bog standard '51,  whilst a "Model T" performancewise, is still
> 
> available 25 years on.
> 
>>Don't get me wrong, I think the AVR is a great device, but will the one
>>I used in my last design still be around in 2030....
>>M
> 
> 
> 25 years ago (1980) you probably were running 8051 micros in a 4 or 5 um
> process.
> The chips would be approximately 100 times larger than with a 0,35 um
> process.
> I much doubt that you will find any such parts in production today.

  No, but you WILL find a device that can swallow the _same_ HEX file,
and plug into the same socket.

  On the more general part longevity angle, you might be surprised :
  I noted with some bemusement a chip programmer we sell, recently
added ( Aug 2004 ) an Intel 87C42 to the device list.
Clearly, someone must have asked.... and I see Digikey do still list 
these, as do 2 other distis.


> The first generation of parts have gone through a shrink process.
> I can't think of an AVR part which is obsoleted without a replacement part.

Depends on how you qualify 'replacement part' ?

Some of the Atmel "Migrating from.." guides make scary reading, from
a product support viewpoint.


> When the shrink is done, there is a significant effort to make the chips
> compatible with the old parts.

  That's what one would hope, but WHY do they so often make it 
impossible to run the same binary ?

  This must make it a support nightmare, for anyone who has to manage 
code changes across a mixture of EOL AVRs and 'this years models' ?

  Probably does not matter in an ASSP, or a cell phone, but many embedded
products have long life cycle, SW support structures.

-jg

>   No, but you WILL find a device that can swallow the _same_ HEX file,
> and plug into the same socket.

> > The first generation of parts have gone through a shrink process.
> > I can't think of an AVR part which is obsoleted without a replacement
part.
>
> Depends on how you qualify 'replacement part' ?

Can be tough to add features and stay compatible with binaries
if parts are used in the wrong way.
Did a port from a m163 to a m16.
the main problem was that the EEPROm was somewhat slower,
and the original programmer looked at the datasheet
and made a delay loop until the EEPROM should definitely be ready.
In another part, they read the UART and assumed that the UART receive buffer
was empty.
I changed to code so it would work with both the m163 and the m16.
With a good compiler it is not so hard to maintain versions.
If you reprogram something, then the programming application
needs to know which chip it is, and select the correct binaty.
You can read out a signature and determine this on an AVR.
AVR Studio woudl not be able to do it easily though,


> Some of the Atmel "Migrating from.." guides make scary reading, from
> a product support viewpoint.
>
>
> > When the shrink is done, there is a significant effort to make the chips
> > compatible with the old parts.
>
>   That's what one would hope, but WHY do they so often make it
> impossible to run the same binary ?

Valid point.

Peripherals change and they design them to have consecutive addresses, I
guess.

Two-three years ago they started specifying the I/O map.
Previously, this was more or less ad-hoc.
Currently, a range of chips is built from each database
and the chips in the same family is thuus
much more compatible.

The small I/O space is a problem, and things are changing to use this
in more efficient ways.




>   This must make it a support nightmare, for anyone who has to manage
> code changes across a mixture of EOL AVRs and 'this years models' ?

Need a compiler which supports multiple versions.
It is not so hard to recompile multiple versions using the IAR compiler.


>   Probably does not matter in an ASSP, or a cell phone, but many embedded
> products have long life cycle, SW support structures.

I guess that is part of the learning process. It is improving.

>
> -jg
>

On Wed, 19 Jan 2005 18:17:43 -0500, the renowned "mc"
<m...@uga.edu> wrote:

>
>"Nicholas O. Lindan" <s...@sig.com> wrote in message 
>news:ZuwHd.646$c...@newsread2.news.atl.earthlink.net...
>> "Yukuan" <y...@kkcity.com.tw> wrote
>>
>> Do what you know: as in the catch phrase: "Building on core
>> competencies."  Master something new when you _have_ to.
>>
>> Chasing after the uP of the month will leave you knowing
>> a little bit of everything, but not knowing a lot about
>> anything.
>
>Right.  And in fact it is better to master one of them, and then switch at a 
>later stage, than to switch around all the time without ever mastering any 
>of them.

Like human languages, once you really master a couple of them, the
next one generally comes fairly easy. 



Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
s...@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Nicholas O. Lindan <s...@sig.com> wrote:
> > l...@larwe.com wrote
> > >Nicholas O. Lindan writ:
> > >
> > > > Second sourcing is still important in industrial products.
> > > > A uP without a viable producing second source won't (shouldn't)
> > > > get designed in.
> > >
> > > There are VERY few uCs with second sources.

> My guess is those might be the ones that will still be around in 25 years.

Some architectures have (open source) FPGA cores available, which will help
long time availability. 

Bye
-- 
Uwe Bonnes                b...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

In article <41ee950d$1...@mustang.speedfactory.net>, mc
<m...@uga.edu> writes
>AVR:  tools available from one manufacturer;

Not true. several manufacturers to tools for the AVR (it's just not
many)

> AVR Studio is free;

As are many 51 tools

> some 
>compilers have free evaluation versions; 

Most commercial compilers do. Though check they are not time limited. 

>STK-500 development kit is cheap.
Are there any others? there are 100's of 51 dev kits.


>8051:  no single manufacturer supports it any more;

No about 40 do for Silicon and a lot  more with tools  I think you will
find that virtually every silicon and IP core/fpga and ASIC manucafurer
has a 51 core. The same can not be said for the AVR.

Also the 51 family is being constantly developed. There are man new
derivatives and die shrink versions being produced that will of course
still all run the 8031 binary from the originals.


There are even versions with JTAG debugging.

> tools are freeware (old) 
>or commercial; 

The many many tools are:-
Free ware , old and new (there are new freeware 80561 compilers being
release now. SDCC for one.

A vast area of sharware and inexpensive 52 tools both SW and HW. 

Virtually ALL commercial tools manufacturers do an 8051 tool set. Again
the same is not ture for the AVR.

Some of the best (safety critical standard) compilers have free versions
that are size not time limited that are great for small projects.

there are 8051 tools that run on windows, linux and Unix.

>lots of code already exists.

Yes. and LOTS of dev kits most of the 40 plus silicon vendors do their
own kits (multiple) and so does almost every other dev kit maker on the
planet.

Basically for every 1 of an AVR  tool/ code example/ etc there will be
50 in the same category for the 8051 for the 8051

The AVR is single source with comparatively few tools. The same is true
of the Philips XA. It does not make them bad parts. Technically both are
VERY good. 

However unless you are doing this as a hobby there are many other
factors involved which may not make the best chip (technically) the
right part for the project. 


There are many reasons for choosing the AVR or XA. Not all of them are
obvious.  In theory the Qwerty keyboard is the woest design for a
keyboard. This has been known for years but alternatives are rare in
use.


Regards
 Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/