> Hi all

Hi Mahmood!

> We are all great fans of the pic, I'm trying to use the PIC16F877 for a
> project, my boss is forcing me to use 8051, I need 30 I/O lines
> including 2 serial ports and eeprom space where my F877 fits perfectly.
> I searched through most of the 8051 family but couldn't do it with a
> single chip.

As people have pointed out, if you are willing to look at different versions
of the 8051, you can find something that will fit your I/O needs.

> He argues that the pic has awkward architecture with small memory map
> and poor support for compilers. Looking at the F877 I think it's the
> opposite, it has large memory and a great architecture and lots of
> peripherals and 2 fast, there are also lots of good compilers around.

You later put in:

> I already had a big fight with him over other things, don't want to make
> it any bigger, he gave me an 8051 biased application note to read about
> how to chose a microcontroller its at
>
www.egr.msu.edu/classes/ece482/Reports/appnotes/98spr/tsaimelv/appnote.html
> I already showed him on paper the difference between the 2 but I think
> the real reason he refuses is that he never used a pic before in his
> life. And also that appnote might be comparing PIC16C54 to the 8051
> family which is unfair.

> Any suggestions, comments, feedback welcome.

First off, I would consider the 8051/8052 MCU to have two clear advantages
over the PIC16F877:

1.  If you have to add eight bit peripherals to your application, the
8031/8051/8052 chips are superior in this regard.  I have put in 8 bit I/O
devices on PIC17C4x's, but these are more expensive and do not have Flash
program memory.

2.  The 8051 can run an RTOS more efficiently than the PIC16F877.  The
PIC18C/Fxxx give the PICmicro MCU similar capabilities, but they don't have
the ICD of the PIC16F877.

Where the PIC16F877 has a clear advantage is in regard to ICD coupled with
MPLAB - for a low cost in-circuit debugging solution, I do not believe that
there is a comparable 8051 product.  You could argue that a debugger written
for the 8051 could be used similarly, but you wouldn't get all the features
of ICD and certainly not the source code level interface of MPLAB/ICD.

As others have pointed out, the web page your boss has pointed has a number
of significant inaccuracies (I wouldn't call them biases because I saw some
pretty outrageous things said for all the devices).  Looking at my 1982
Intel datasheets, it's interesting to note that Intel calls the 8051 a "RISC
device".  Where I would go back to your boss is noting that the page is 4
years old.  Devices like the PIC16F877 did not exist when the page was
created.


What you didn't indicated is what you are designing and how many are going
to be built.  I think the PICmicro MCU has an advantage in terms of
development tool cost and availability.  Microchip has done a very nice job
with MPLAB, PICSTART Plus, PICMASTER, MPLAB ICE, and so on along with
enabling compiler writers and tool vendors.  8051 vendors have not been so
proactive and have made available the breadth and quality of the tools
available for the PICmicro MCU.

My gut feeling is that feature for feature, you can get a PIC16F877 cheaper
than a comparable '51.  But...

You never know when somebody's going to find a skid of parts in a warehouse
that are available for a nickel on a dollar - if this has happened in the
past, you'll probably get told of that quite a bit.  You can, however, note
that Digi-Key has chosen the PICmicro MCU as their primary line and really
have done a lot to support the different devices and make sure the prices
are good and supply is consistent.  Look at companies like Future-Active
(that carries both the PICmicro MCU and 8051 part numbers) and see what the
prices are like.


If I were in your position, I would first really try to understand why your
boss is insisting on using the 8051.  Does he have a relationship with a
company/supplier?  Is he your boss because he made a home run in the company
using the 8051?  Are there any other emotional reasons why he would insist
on the 8051?


If it comes down to ignorance about the PICmicro MCU with no strong
emotional baggage associated with the 8051, you can make the following
statements noting:

1.  That since you are going to be developing the application in a HLL, so
the processor architecture is irrelevant.

2.  You are not going to require the features of the 8051 that clearly
differentiate it from the PICmicro MCU.

3.  You can get much better development tools for a given amount of money
(ie $1K USD will get you a "C" compiler integrated into MPLAB along with ICD
and probably enough money left over for a PICSTART Plus).  I *know* you
can't get comparable 8051 tools for this amount of money.  Depending on your
company's size, you will probably be able to expense rather than make
capital purchases for PICmicro MCU development tools, which avoids a lot of
hassles for your boss.

4.  You feel that over the long term, you will be able to get consistently
get parts with superior pricing on the PICmicro than on the 8051.  In terms
of parts availability, I have never heard anything bad about Philips
(although I have heard complaints about other 8051 manufacturers) and
Microchip is always very good (except for their habit of announcing products
before they're able to ship good silicon).  Look at different distributor's
web pages and print out quantity pricing for 100, 1,000 and 10,000 units for
vendors that sell both architectures.


Don't get into arguments over which architecture is better - I can come up
with convincing arguments that the 8051 is better and then come up with a
similar number of arguments that the PICmicro is better.  The four points
above are pretty unemotional and hard to debate.


As somebody already noted, at the end of the day, your boss is still your
boss, so if he insists on the 8051, it's probably in your best interest to
go with the 8051.

Good luck.

Comments on this from anybody else?

myke

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.