PIC versus AVR

I don't want to start a religious war, but could a few knowledgeable people 
give me their impressions of the relative advantages of PIC vs AVR?  Assume 
that I will be using both, to some extent, for some time, and want to know 
what their relative advantages are.  Throw in MSP430 too if you'd like.

I'm mostly using PICs right now but am stuck on the fact that MPLAB requires 
you to have write permissions in C:\Program Files (which we can't allow in a 
big student lab with roaming profiles), and also, if you follow the 
simplest, default path toward creating an ASM project, you run into a 
62-character length limit on the full path to the file.  Does AVR Studio 
cooperate fully with normal Windows security practices, or does it, too, 
require you to loosen security on the computer in order to run it?

mc wrote:
> I don't want to start a religious war, but could a few knowledgeable people
> give me their impressions of the relative advantages of PIC vs AVR?  Assume
> that I will be using both, to some extent, for some time, and want to know
> what their relative advantages are.  Throw in MSP430 too if you'd like.

Well, gee, I only just finished writing several thousand words on the
topic... here's the dime version:

PIC - Broad range of functionality and some special-purpose devices.
Can be inexpensive. Architecture is baroque and horrific. My
recommendation: only for small projects implemented entirely in
assembly language by confirmed masochists.

AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
broad range of devices. Much closer compatibility in the family than
amongst the different PIC flavors.

MSP430 - 16-bit, high performance, low power, von Neumann architecture.
VERY easy to work with. Code compatibility between parts is superb.
However, relatively expensive and not many devices in the family.

All three - Proprietary single-source architectures.

mc wrote:
> I don't want to start a religious war, but could a few knowledgeable people
> give me their impressions of the relative advantages of PIC vs AVR?  Assume
> that I will be using both, to some extent, for some time, and want to know
> what their relative advantages are.  Throw in MSP430 too if you'd like.
>
There are no show stoppers for using any of these (PIC,AVR, and
MSP430), the one I choose for a particular project is the one has the
necessary amount of peripherals in the smallest package size, all
things being equal I will choose the MSP430 over a AVR, and the AVR
over the PIC.

MSP430 is 16 bits, has the highest performance analog I/O (and not
surprisingly is the most expensive and biggest in physical size). I
prefer the AVR architecture over the PIC, but the PIC is cheaper and
has better availability and more choices.

The application chooses the chip for me, though

larwe wrote:

> All three - Proprietary single-source architectures.

there are multi-source architectures?

> Well, gee, I only just finished writing several thousand words on the
> topic... here's the dime version:

Previous postings here, or something else?  I'd be glad to read it if you've 
made a web site or something...

> PIC - Broad range of functionality and some special-purpose devices.
> Can be inexpensive. Architecture is baroque and horrific. My
> recommendation: only for small projects implemented entirely in
> assembly language by confirmed masochists.

*chuckle*  That's me :)

> AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
> broad range of devices. Much closer compatibility in the family than
> amongst the different PIC flavors.

So I had noticed.  It may be a bigger instruction set, but there are fewer 
flavors of it...

> MSP430 - 16-bit, high performance, low power, von Neumann architecture.
> VERY easy to work with. Code compatibility between parts is superb.
> However, relatively expensive and not many devices in the family.

Ah!  Didn't realize it was Von Neumann.  Hmmm...  A lot of what I do is 
precision timing of one kind or another, and the ability to count to 65535 
might be useful.

> The application chooses the chip for me, though

That's as it should be, of course.  A wise engineer knows the relative 
merits of many different tools and will choose the one that is the best for 
the job.

On 3 Aug 2006 19:24:13 -0700, the renowned "steve"
<bungalow_steve@yahoo.com> wrote:

>
>larwe wrote:
>
>> All three - Proprietary single-source architectures.
>
>there are multi-source architectures?

8051 & ARM, for example. 

In article <WMxAg.42352$Nt.39355@bignews8.bellsouth.net>,
 "mc" <look@www.ai.uga.edu.for.address> wrote:

> Does AVR Studio 
> cooperate fully with normal Windows security practices, or does it, too, 
> require you to loosen security on the computer in order to run it?

I stay as far away from Windows as I can, so I can't say that I've 
looked deep enough at AVR Studio to answer your question. But I can say 
that the Atmel team appears to be trying harder than the Microchip folks 
at providing development tools. And unlike Microchip its actually 
practical to code and debug an AVR without Windows.

AVR-gcc is a very good compiler. The packager of WinAVR (avr-gcc for 
Windows) is now an Atmel employee. See above about "trying harder."

I realize in an academic environment at least one stage of the learning 
process one stays limited to assembler. Once students get used to 
assembler it can be enlightening for them to study the output of a C 
compiler. I looked a lot at the output of avr-gcc. It never wrote 
assembly that I could improve enough to justify the effort to rewrite in 
assembly. Once or twice I changed a C expression for better assembly 
output.

David Kelly wrote:


> compiler. I looked a lot at the output of avr-gcc. It never wrote
> assembly that I could improve enough to justify the effort to rewrite in
> assembly. Once or twice I changed a C expression for better assembly

Mmm, maybe. I'm currently evaluating avrgcc (with which I have a lot of
experience) against IAR and Rowley (with which I have relatively little
experience on AVR targets). There _are_ differences.

steve wrote:
> larwe wrote:
> 
> 
>>All three - Proprietary single-source architectures.
> 
> 
> there are multi-source architectures?

Oh yes :  80C51, ARMx, MIPs, C166, x86.....

-jg