EmbeddedRelated.com
Forums

PIC versus AVR

Started by mc August 3, 2006
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