> > Some architectures have (open source) FPGA cores available, which will
help
> > long time availability.
>
>   Quite true, but the long-term fish-hooks in Soft-CPUs are the silicon
>   supply, and the software tools themselves.
>   There really needs to be a certain 'critical mass' - and the C51
> easily meets that.
> -jg

For CPU + FPGA development, you really want to
have coverification, and AFAIK there are two ways to get that;
Send a $125,000 check to Mentor, or get the $100 STK594...


>

Uwe Bonnes wrote:
> Nicholas O. Lindan <see@sig.com> wrote:
> 
>>>larwe@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. 

  Quite true, but the long-term fish-hooks in Soft-CPUs are the silicon 
  supply, and the software tools themselves.
  There really needs to be a certain 'critical mass' - and the C51 
easily meets that.
-jg

In article <41ee950d$1@mustang.speedfactory.net>, mc
<mc_no_spam@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    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nicholas O. Lindan <see@sig.com> wrote:
> > larwe@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                bon@elektron.ikp.physik.tu-darmstadt.de

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

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

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

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

"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/

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 \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/