Beginner Q: Starting out in embedded systems dev

>But going back to the first point.. you cant go wrong with an 8051...
>actually you can. lots. but it is a good place to start which is why
>there are over 50 manufacturers producing 600 different versions that
>will all run the same core binary.

Just what is this love affair with the 8051 all about? Apart of course your
commercial interest. This processor is 30 years old, it has a primitive
instruction set not suited to running pointer intensive languages like C. It
has an architecture which is just as usuited to C as well. The chips themselves
are not fast, not cheap nor allways available, apart from the basic 40pin
version. I can't think of a single good reason for using them these days, if
you can then maybe you can enlighten me.

> >But going back to the first point.. you cant go wrong with an 8051...
> >actually you can. lots. but it is a good place to start which is why
> 
> Just what is this love affair with the 8051 all about? Apart of course your
> commercial interest. This processor is 30 years old, it has a primitive

Chris and I don't see eye-to-eye on quite a few things, but we argue
quite cordially :) His [other] schtick is, in a nutshell, that the '51
is so widespread that it's a good learning platform because (a)
there's tons of IP out there waiting to be reused, and (b) it's a good
bullet point on the resume.

To which I would add (c) if you can program the '51 skilfully, you
won't have trouble programming an elegant architecture, much like a
driver trained on a Yugo won't have much trouble driving a Bentley.

I don't regret the time I spent learning how to program this platform.
Among other things, there are a _load_ of ASSPs that use a 51 to do
the grunt bit-shuffling work, transferring data into and out of
special-purpose hardware on the chip (crypto, A/V codec, etc). Used to
be that it was the price king, and I guess as a soft core it still is.

(My potential new employer uses '51s and - ARGH! - COPs, but -
amazingly - is migrating some applications to AVR and is dabbling in
MSP430, too! I am so happy! Ulf, are you reading this?).

CBarn24050 wrote:
>>But going back to the first point.. you cant go wrong with an 8051...
>>actually you can. lots. but it is a good place to start which is why
>>there are over 50 manufacturers producing 600 different versions that
>>will all run the same core binary.
> 
> 
> Just what is this love affair with the 8051 all about? Apart of course your
> commercial interest. This processor is 30 years old, it has a primitive
> instruction set not suited to running pointer intensive languages like C. It
> has an architecture which is just as usuited to C as well. The chips themselves
> are not fast, not cheap nor allways available, apart from the basic 40pin
> version. I can't think of a single good reason for using them these days, if
> you can then maybe you can enlighten me.

  I must have missed the release of the 100MHz AVR - or the 24 Bit ADC 
MSP430, or the USB_PIC ?
  Last time I looked at an AVR, the BOOLEAN handling was primitive, and
there was no register bank switching : since those two things mattered
more in the task at hand, the 80C51 won hands down.
  The 80C51 was designed as an embedded microcontroller, and it still
excells at that task.
  Like all devices, it has a certain natural Opcode Data and Code 
'reach' and outside that, it becomes less efficent. A microprocessor it 
is not.

  If you/your application likes C, and lots of pointers, then the
new ARM controllers will make you right at home.
  Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
old ? :)

-jg

Jim Granville <no.spam@designtools.co.nz> says...

>Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
>old ? :)

A microcontroller is like a girl; when it's less than 18 years old, 
I lose interest.  :)

Guy Macon wrote:
> Jim Granville <no.spam@designtools.co.nz> says...
> 
> 
>>Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
>>old ? :)
> 
> 
> A microcontroller is like a girl; when it's less than 18 years old, 
> I lose interest.  :)

Wot - no '& when it's over YY years old, you also lose interest" ? ;)

>>Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
>>old ? :)
>
>A microcontroller is like a girl; when it's less than 18 years old, 
>I lose interest.  :)
>

it has nothing to do with fashion, if you want to use old stuff thats fine with
me. I'm still waiting for someone to mention a single factor that makes the
8051 more suitable for a new design.

CBarn24050 <cbarn24050@aol.com> says...

>I'm still waiting for someone to mention a single factor that makes the
>8051 more suitable for a new design.

You just read about three of them:

  "I must have missed the release of the 100MHz AVR
   or the 24 Bit ADC MSP430, or the USB_PIC"
                                 -Jim Granville 

Those are factors that makes the 8051 more suitable for a new design.

When you wrote "it has a primitive instruction set not suited to
running pointer intensive languages like C. It has an architecture
which is just as unsuited to C as well" I think you expressed your
real objection, and a fine objection it is - for those who program
microcontrollers in C.  That's the high end.  Down here where the
chips cost less than a dime and the programs are less than 100
bytes long we use assembly language and ponder whether to use an
8051 with onboard peripherals or a 4-bit processor with external 
peripherals.

-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

On 26 May 2004 09:29:33 GMT, the renowned cbarn24050@aol.com
(CBarn24050) wrote:

>>>Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
>>>old ? :)
>>
>>A microcontroller is like a girl; when it's less than 18 years old, 
>>I lose interest.  :)
>>
>
>it has nothing to do with fashion, if you want to use old stuff thats fine with
>me. I'm still waiting for someone to mention a single factor that makes the
>8051 more suitable for a new design.

Say you want a 24-bit delta-sigma DAC on board.. AFAIK only the 8051
core is available in production quantity (at least two suppliers),
with ARM availability (one supplier) projected to be in 3rd quarter
2K004. There are other similar examples. 

More generally, why in the world would you reject a competitively
priced 8051 from consideration in an application where it would be
appropriate?  For example, the modern Philips 6mm x 6mm P89LPC932FHN.
 
http://www.semiconductors.philips.com/pip/P89LPC932BA.html

Or an inexpensive OTP P87LPC760BDH (USD0.87 ea/reel from Avnet) 
http://www-us.semiconductors.philips.com/pip/P87LPC760BDH.html


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

CBarn24050 wrote:
> it has nothing to do with fashion, if you want to use old stuff thats fine with
> me. I'm still waiting for someone to mention a single factor that makes the
> 8051 more suitable for a new design.

  more suitable than what ?
Since the 80C51 is proven, widely available, multi-sourced, low cost, I 
tend to work from the angle that if a controller can do something the 
80C51 cannot, then it might get a look in.
  [It will help a lot if the alternatve it is multi-sourced]

  It may not even be the core that dictates, but a peripheral :
eg if you want 24 bit ADCs in a uC, your choice is [guess what core :)]
or if you want Ethernet+Flash that might point to the eZ80.... etc

  Thus, I can forsee using an ARM variant, when the maths loading
dictates, but otherwise change just for the sake of it has low appeal.

-jg

On Wed, 26 May 2004 16:49:35 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

[...]
>  I must have missed the release of the 100MHz AVR 

They're up to 20 now.  And they've always been single-cycle machines.
With an "8051," you're never sure if it's 1, 3, 4, 6, or 12 (Yes, I
see the SiLabs C8051F120 is ostensibly a single-cycle machine).

>           - or the 24 Bit ADC 
>MSP430, 

Forgive me if I'm skeptical about a microcontroller's ability to
distinguish 300 nanovolts (or 180 with a 3 volt reference).  If I
needed that kind of accuracy, I'd want the ADC a little further away
from the CPU clock...

>              or the USB_PIC ?

I can understand that.  They're pretty new.  Check the Microchip web
site.  The PIC16C745 and 765 support USB 1.1, and the PIC18F2455,
2550, 4455 and 4550 support USB 2.0 (Full Speed, not Hi-Speed).  All
these chips were released in the last two months.

Not that I much like PICs...

>  Last time I looked at an AVR, the BOOLEAN handling was primitive, and

AVR has a Load/Store architecture -- most operations take place on
data in the registers.  Setting or clearing a bit in a register is one
single-cycle instruction (SBR, CBR).  The compilers I use reserve up
to 13 general-purpose registers (104 bits) for boolean storage.
Assigning the value of one boolean to another requires 2 single-cycle
instructions (BST/BLD).

>there was no register bank switching : since those two things mattered
>more in the task at hand, the 80C51 won hands down.

Register bank switching can save some time if you have a lot of
interrupts occurring that need to be serviced fast.  With the AVR, you
need to save whatever registers you're going to use yourself.  There's
a 4-cycle penalty per register (two to save, two to restore).  

PICs are horrid when it comes to interrupts -- there is only one, and
you have to perform an amazing dance to save state, then you have to
find out who generated the interrupt (generally by polling device
status registers).

The 8051 only lets you access 128 bytes of RAM without going through
the DPTR, and at least 8 of those are reserved for registers (and 8
more for each additional register bank).  But the AVR can load a value
from any location in RAM in 2 cycles, and has 3 16-bit indirect
address registers.  Dual DPTR is only available in extended 8051
cores.  Implementing the functionality of something like memcpy on a
single-DPTR core is... painful.

>  The 80C51 was designed as an embedded microcontroller, and it still
>excells at that task.
>  Like all devices, it has a certain natural Opcode Data and Code 
>'reach' and outside that, it becomes less efficent. A microprocessor it 
>is not.

The one primary and overarching advantage of the 8051 is the fact you
can buy it from multiple sources.  This provide competition and a
multitude of options.  Finding a plug-in replacement for a particular
chip, however, can be... difficult.

And every time I've tried to get an 8051 into a design, the budgetary
10k pricing has been way out-of-line.  Cygnal (SiLabs) in particular.
Budgetary pricing >3x the next highest competitor lost the battle
before it started.

If the AVR were multiply-sourced, we'd see them at 100 MHz and in the
automotive temperature grades (though perhaps not in the same
device...).

>
>  If you/your application likes C, and lots of pointers, then the
>new ARM controllers will make you right at home.
>  Or maybe not, as ARM fails the 'fashion test', being close to 20yrs 
>old ? :)

ARMs are overkill for most applications I've worked on the last 4
years.  The AVR does a really nice job at a low cost, and is
relatively C-friendly.  The avr-gcc compiler is very good.

From a software standpoint, the AVR is my first choice for an 8-bit
microcontroller (If you haven't guessed that by now  ;-).  From a
hardware standpoint, the only real problem I've had is temperature
grades.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.