> > I think that the RISC approach to have load/store and many registers is
well
> > proven
>
>   Well proven for what - proven to consume code memory in the many index
> loads that are needed ?

What you loose by having to load memory, you gain by not having to write it
back all the time.
I think compiler output of real applications proves that.
Odd benchmarks which focuses on a specific strengths of a microcontroller
will always confuse the issue.

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.

>   RISC made sense when memory was off chip, and large, but in a 8 bit uC
> you can have working poduct in 64-256 bytes RAM, so it only makes sense
> to have opcodes that can directly access that ? - see the Z8 for a
> example of a register-register uC design that understands that.

If your application fits in 64 bytes SRAM you are probably much more
efficient
if you can use the internal 32 registers for the most used data.

When you need to work with devices needing large amount of SRAM
like USB Host controllers, then you lose out, since the USB host stack
requires 64 kB in itself, and then you have to add space for the
applications.

Noone has made a mobile phone based on the 8051 AFAIK, since
you use megabytes of code. Plenty use the AVR for cellular phones.

If you only want to

> >>interrupt structures
> >
> >
> > AVR interrupt processing is limited to 6 clocks, and the good compilers
> > will not cause excessive push/pops.
> > For real high performance you can use global variables in registers,
even in
> > C,
> > so no PUSH/POP is needed. Not even the PSR needs to be pushed
> > if the instructions in the interrupt handler does not update the PSR
> >
> > Very few chips on the market have as fast interrupts as the AVR.
>
>   The C51 has register bank switching, and the direct memory and boolean
> opcodes mean you can write functioning interrupts without pushing
> anything. Most C51s now have FOUR int priority levels as standard.
> AVR Int priority handling ?

So you can write AVR code and 8051 code without pushing anything.
While priority levels are nice, this has not been mentioned by a single
customer.
My conclusion is that most people do not need nested interrupts.

> >>speed
> > A 100 MHz 8051 will not be faster than a 48 MHz AVR which is the current
top
> > of the line for std micros
>
> Wow - I missed the release of the 48MHz Flash AVRs - where can I get some
?

AT76C713 = 48 MHz which is an SRAM device but also is a standard micro.
Actually runs faster, but then the USB does not run at that speed.

Atmel uses 0,18u for the ARM7 where the flash will run at 48 MHz in room
temperature.
Needs to degrade to 30 Mhz at industrial temp range.
A 7-8 ns flash if available is impressive.

>
> >>Analog performance,
> >
> >
> > 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 ?! ]

They needed more than 10 bit resolution for their product
and managed to do it with the AVR ADC.

> ALL of the highest performance Analog 8 bit uC's out there, (and there
> are many :ADi, BB, SiLabs, TDK ), use the 80C51 core.
>

Availability of third party IP allowing anyone to build a C51 controller
strengthens the C51 market.
I think anyone that could legally get their hands on the AVR core would
prefer to use that in their chips.

> >>smallest packages, ....
> >
> >
> > 4 x 4 mm available for the smallest AVR.

> That puzzles me - if the AVR core is so tiny, then how come
> SiLabs can ship an 8K/256R+ADC device in 3mm, and now Philips too have
> 3mm C51 devices 1K/128R+ADC (both with 10/11 pin MLF), how is it that
> the 8 pin Tiny13 (1K/64R) die has to go into the 4mm MLF20 package ?

The core is only a small part of the device.
So far I have only had one significant customer asking for 3 x 3 mm, but
when we showed the pinout of the 4 x 4 mm tiny13, then they said
that since there is only need for routing in the east-west direction and not
north-south
and decided to drop their current 3 x 3 mm micro because they like the AVR.

I think in this case some companies may be using more aggressive technology
like 0,18u.
This typically means dropping 5 V capabilites.


>
> -jg

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

"Ulf Samuelsson" <u...@NOSPAMatmel.com> wrote in
news:3...@individual.net: 

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

"Mike Diack" <m...@kcbbs.gen.middleearth> wrote

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

JC Whitney still carries new piston rings, valves, distributors and 
such for the Model T.  If enough are made, for a long enough time,
then parts will be around forever.

This is something _very_ important to consider in the embedded world.

This is all old-hat to those wearing old-hats, but for those starting
out:

Any uP used in cell-phones seems to have a 1-year lifespan, just
like the cell phone it is designed into.  Motorola obsoleted
several cell phone wonders before production quantities became available.

Industrial controls are produced for some 30 years.  Upgraded
all the time, but it's the same basic system with the same uP.  It is
the same with mature consumer goods: ranges, washing machines, mixers,
etc.. 

Second sourcing is still important in industrial products.
A uP without a viable producing second source won't (shouldn't)
get designed in.

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?  

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

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.

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

Nicholas O. Lindan wrote:

> 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. Even for a popular core
like 8051, every vendor adds their own twists and niggles (at least) or
massive add-on functionality slices. So this requirement restricts you
to a tiny number of specific devices. If you're buying a 4K/256b OTP
8051 variant from vendor A with second source at vendor B, moving up to
8K/512b might turn the part into single-source again.

At my [Fortune 50] employer we regard all uCs as single-source
products. We do not design in a uC unless we have a guaranteed 5-year
buy life on the part. We use truckloads of COPs (though, we do not use
them in new designs), specific 8051s, venerable HPCs, ...

In article <1...@c13g2000cwb.googlegroups.com>,
l...@larwe.com writes
>
>Nicholas O. Lindan wrote:
>
>> 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. Even for a popular core
>like 8051, every vendor adds their own twists and niggles (at least) or
>massive add-on functionality slices. So this requirement restricts you
>to a tiny number of specific devices. If you're buying a 4K/256b OTP
>8051 variant from vendor A with second source at vendor B, moving up to
>8K/512b might turn the part into single-source again.
>
>At my [Fortune 50] employer we regard all uCs as single-source
>products. We do not design in a uC unless we have a guaranteed 5-year
>buy life on the part. We use truckloads of COPs (though, we do not use
>them in new designs), specific 8051s, venerable HPCs, ...

However as there are about 600 odd 8051's out there if the one you use
disappears there will be a very similar one fro some one else that will
do the job. You have the same basic architecture and tools. If the SWis
well designed you will probably only have to adjust a few lines of code.

So whilst there are few pin compatible second sources there are a lot of
near misses that require very little hassle to use. 


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

Chris Hills wrote:

> >There are VERY few uCs with second sources. Even for a popular core
>
> However as there are about 600 odd 8051's out there if the one you
use
> disappears there will be a very similar one fro some one else that
will

In my field, as in many others I think, the porting effort (SW/HW
engineering time) is trivial compared to the length and expense of the
testing and qualification process that follows it. If we change a part
number and firmware, we need to go through a minimum of three months QA
functional testing (this usually takes > 4 months due to resource
availability) and in most cases also FCC and UL re-cert. UL leadtimes
are being quoted as 16 weeks now. All in all, it takes at least six to
seven months to pull this "trivial" change through the pipeline, not
counting production ramp-up and component leadtimes (some of our mask
parts have 15-18 week leadtimes and that clock often cannot start to
tick until regulatory approval is finished).

Historically we have seen it takes our team about 2 weeks to take a C
project and port it to an *entirely* different microcontroller, and
this can almost always run in parallel with the HW respin. It might
only take a day or two to port to a similar micro, such as the
situation you describe, but the 8-9 days thus saved are irrelevant
compared with the 168-196 days of process after that.

I know you have a hard-on for the 8051 ( :) ) and there are other
issues where we disagree too, but in our situation the "somewhat
retargetable" nature of 8051 code is lost in the noise compared to the
other hell that surrounds changing parts. We were talking here about
second-sourcing, where one can switch between suppliers with utter
transparency. The engineering time required to port between parts that
aren't pin-compatible, binary-compatible, feature-compatible drop-in
replacements isn't part of the issue.

On 2005-01-20, l...@larwe.com <l...@larwe.com> wrote:
> Chris Hills wrote:
>
>>> There are VERY few uCs with second sources. Even for a popular
>>> core
>>
>> However as there are about 600 odd 8051's out there if the one
>> you use disappears there will be a very similar one fro some
>> one else that will
>
> In my field, as in many others I think, the porting effort
> (SW/HW engineering time) is trivial compared to the length and
> expense of the testing and qualification process that follows
> it. If we change a part number and firmware, we need to go
> through a minimum of three months QA functional testing (this
> usually takes > 4 months due to resource availability) and in
> most cases also FCC and UL re-cert.

Your scenareo is a bit worse than most of the projects I've
worked on. But, I'd have to agree that unless the second part
is pin-for-pin, drop-in, same-part-number-on-the-BOM comptable,
changing to a different architecture just isn't much more work
than changing to a "similar" part with the same ISA but
different pinouts and peripheral interfaces.  

Once you've got to re-layout the board and re-write the
peripheral handling code, you can almost as easily switch to
different architecture.

The last time I worked on a project with an honest
second-sourced CPU it was 15 years ago using an 8086 in a DIP
package.  IIRC, the signal thresholds on one of the interrupts
pins weren't _quite_ the same on the two parts, and some
component value changes actually did have to be made when
purchasing decided to by the parts from the second source. :(

-- 
Grant Edwards                   grante             Yow!  Of course, you
                                  at               UNDERSTAND about the PLAIDS
                               visi.com            in the SPIN CYCLE --

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

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.

When the shrink is done, there is a significant effort to make the chips
compatible with the old parts.
On the other hand, there is a market requirement for more features so the
feature set
cannot remain the same.

When the requalification costs are high, you have a problem, and need to
solve that by buying enough stock to last you.
I doubt that this problem is generally solved by choosing an 8051
architecture chip.
All 8051 chips from Atmel go through shrinks as well.
The change from AT89C51 to AT89S51 is not that great, but will need requal.

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

> Any uP used in cell-phones seems to have a 1-year lifespan, just
> like the cell phone it is designed into.  Motorola obsoleted
> several cell phone wonders before production quantities became available.
>

ATtiny28V is in a cell phone, and was in a cell phone one year ago, and
in another one previously. Then is was not specifically developed for a cell
phone.

> Industrial controls are produced for some 30 years.  Upgraded
> all the time, but it's the same basic system with the same uP.  It is
> the same with mature consumer goods: ranges, washing machines, mixers,
etc..


> 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 severly limited if this is a requirement.

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

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

This is highly depending on the strategy of the product line of the company.
Atmel has product lines with an ASSP strategy, and other product lines with
a standard product portfolio strategy.
Both the AVR and the AT91 are standard product with long lifetime.
The AT76 and the AT75 have normally shorter lifetime, although
there are chips where these product lines decide to adopt a standard
approach.
Most notable are the AT75C140 which has been renamed to the AT91C140
to make this fact clear. The AT76C713 is a standard product but
the part still has an ASSP part number.


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

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

Grant Edwards wrote:
--snip--
>
> Your scenareo is a bit worse than most of the projects I've
> worked on. But, I'd have to agree that unless the second part
> is pin-for-pin, drop-in, same-part-number-on-the-BOM comptable,
> changing to a different architecture just isn't much more work
> than changing to a "similar" part with the same ISA but
> different pinouts and peripheral interfaces.
>
> Once you've got to re-layout the board and re-write the
> peripheral handling code, you can almost as easily switch to
> different architecture.
>
> The last time I worked on a project with an honest
> second-sourced CPU it was 15 years ago using an 8086 in a DIP
> package.  IIRC, the signal thresholds on one of the interrupts
> pins weren't _quite_ the same on the two parts, and some
> component value changes actually did have to be made when
> purchasing decided to by the parts from the second source. :(
>
> --
> Grant Edwards                   grante             Yow!  Of course,
you
>                                   at               UNDERSTAND about
the PLAIDS
>                                visi.com            in the SPIN CYCLE
--

Hi Grant,

what about buying and / or learning the new tools if switching
architecture? If you are working as a one man show that penalty might
be minor, however for a team of designers the pain and loss in
productivity is significant.
As an attempt to answer the original question why AVR, why 8051, if you
are familiar with one and not the other, stick with the one as long as
you can get the micro you are looking for.
If you do a new design you might find more 51s with suitable
peripherals than AVRs, simply because there are more out there. Asking
multiple vendors for competitive bits has always been helpful to get a
good price ;-) AVR, one vendor one more or less competitive bit.
For the widest range of high quality peripherals based on 51 core have
a look at Sylabs, looking for the best value in 51 based small chips,
comparible to Tiny AVR look at the LPC900 family from Philips. If you
are looking at MEGA AVR, sopt that! do not start with an 8-bit engine,
go to the "8051 of the 32-bit world" and start developing with an ARM
microcontroller. You get a 32-bit micro for less than $5 that
outperforms any AVR in features and performance while costing less.
An Schwob in USA