AVR or 8051

>   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.

On Thu, 20 Jan 2005 20:30:37 +0100, "Ulf Samuelsson" <ulf@NOSPAMatmel.com>
wrote:

><snip>
>As for selecting C51s many customers would like to reduce their vendors
>and not mess with 10-20 different C51 manufacturers.
><snip>

This is an entirely superfluous comment.  If you want to reduce 20 vendors to 1,
just use 1 and you've reduced them.  Quite simple.  And with the 8051 or ARM
cores, at least, you have a choice about which vendor's business model fits you
better.  I've found this to be a particularly important facet in my own <5000/yr
embedded arena.

There is NO disadvantage in having more than one choice, that reducing them to
one choice doesn't fix.

...

Entirely separately, though, one doesn't "mess with" 10-20 different
manufacturers.  In fact, your own following comment recognizes this fact:

>As for competition, it stops once the part is designed in unless there is
>a true second source.

The "mess with" is only in choosing before that point in time.  And having more
vendors from which to find a better business match *and* more product options is
NOT a disability.  One selects one and goes with it, until there is a reason to
change -- just as you say.  And with the 8051 core or with ARM, at least some of
your time (and possibly money) vested in some of the development tools can be
saved, if circumstances prevent you from staying with the same vendor (and those
reasons can happen no matter the vendor.)

Of course, there are many times that the application itself will mitigate
against either of these, on technical grounds.  But when there is a fit, it's
nice to be able to have some choice in finding more compatible partners.

Jon

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.

> There is NO disadvantage in having more than one choice, that reducing 
> them to
> one choice doesn't fix.

That was Mr. Hobson's great insight :)

In article <1ITHd.2344$rp1.245@newsread3.news.atl.earthlink.net>,
Nicholas O. Lindan <see@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    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Ulf Samuelsson" <ulf@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"
<mc_no_spam@uga.edu> wrote:

>
>"Nicholas O. Lindan" <see@sig.com> wrote in message 
>news:ZuwHd.646$cZ1.388@newsread2.news.atl.earthlink.net...
>> "Yukuan" <ykjiang@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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com