Which is better.. PIC or AVR ?

Click here to go straight to the answer

Whenever this subject comes up on discussion groups, there is invariably a heated debate. This sort of quasi-religious debate has always gone on, I'm old enough to remember people arguing about whether the 6502 was better than the Z80, and I'm sure it went on long before that.

What many people fail to realise, however that in almost all fields of enginering, there is simply no such thing as "Best". The correct phrase is "Most appropriate for your application". Similarly there is no such thing as "good practice" or "bad practice". It all depends on the requirements of a particular product, manufacturing process, development method etc..  Something that would be appropriate to do on a $1000 instrument would often be completely the wrong thing in a $5 mass-market toy.

Here are a few comparisons based on actual issues I've dealt with on real projects. These are mostly based on using assembler on the AT90S and current ATTiny and ATMega parts, and PIC12/PIC16 parts. Hopefully this info will help you decide what may be best for you.

Feel free to contribute more differences you've come across

Ways in which PICs are better than AVRs

Instruction set/architecture (for Assembler users)
PIC good : Small instruction set means you can literally learn it in a day. Skip instructions can often simplify flow-control.

AVR bad : highly nonorthogonal instruction set - many operations can only be done on certain registers. Relative branch range can force code to be arranged in a non-logical order. No immediate XOR instruction. Illogical mixture of skip and branch flow-control instructions (Now if only they'd made STATUS one of the registers you could do skips on....!). 

Clocks etc.

Recent Pics (12Fxxx etc.) have more accurate calibrated RC oscillators.

Watchdog wakeup from sleep continues after SLEEP instruction - on AVR it causes a reset, which can complicate things.

Power consumption
PICs have much lower power consumption at 5V

Interrupts

Interrupt latency is constant - if you set up a regular timer interrupt on a PIC, it will occur at exactly the same interval every time. On the AVR you will get at least one cycle jitter. 

ADC
Much faster conversion speed than AVR

I/O and bit-twiddly things
I/Os are the same as other file registers, so operations other than bit set/clear operations take less work - bits can be toggled using XORWF, multiple bits can be set or cleared simultaneously using ANDWF or IORWF, and you can do neat tricks like using an output port as a shift-register for really fast pattern generation. The latter is not often useful, but does allow neat stuff like video generation.  

I/O ports have much better drive capability - the output high level is easily capable of providing a few milliamps without significant voltage drop - useful for directly powering up peripheral devices (e.g. opamps) on demand for power-saving. 

PIC can wake up from sleep on short pulses and edges. Counters are asynchronous and can count while part is in sleep, and count faster than the CPU clock. AVR cannot wake on edges (Except the few parts that have wake on pin-change), and level-triggered interrupts must be asserted until the chip wakes up and the clock starts otherwise the part will go back to sleep.

Configuring AVR reset pin as I/O disables in-circuit programming. On PICs the reset pin can be configured as an input without disabling serial programming, provided whatever is connected to it allows for the 12.5v programming voltage.

Availability
Microchip have always had a policy of short leadtimes, and there have never been significant shortages of released parts. Atmel have had some very bad times in the past - their wide product range means that AVRs are a small part of their overall business, so other markets can take priority over AVRs for production capacity. Microchip now has a fast-turnaround test cell to produce devices at short notice (with a price premium).
Microchip parts tend to be more easily available, especially in small quantities. 

Microchip keep old parts available for long after they have been superceded. You can still buy PIC16C54XT's, despite now being on their fourth revision. Atmel have far fewer parts, yet have obsoleted more of them - e.g. the 90S4414 has been obsoleted twice (90S8515, now ATMega8515).

Devtools, programming, production etc.
PIC good :
One full-ICE platform (ICE2000) for all parts - Several variants of AVR ICEs for different parts, despite much fewer parts..!
All device configuration including internal eeprom initialisation is contained in one hex file.

AVR bad :
Device configuration etc. is a complete mess - there is no standard file formet to contain flash, eeprom and the many device config fuses, which can be a nightmare when transferring designs to production. There are 3rd party programmers that do this but this is something that should be defined by the manufacturer.
Calibration of internal RC osc on many parts (e.g. tiny26, mega16) is unnecessarily complex - for other than the default 1MHz rate, cal data has to be read from a special area by the programmer, then programmed into flash or eeprom so the application code can get at it to write to the osc cal register. This means that the application code and programming process need to have knowledge of each other, which can be a problem when a design goes to production.

Ways in which AVRs are better than PICs.

Instruction set/architecture

AVR good : Add with carry, and compare with carry simplify multiple precision arithmetic. Good range of conditional branches.

PIC bad : Unconventional mnemonic names.. Only one pointer for indirection. Inefficient lookup tables. No add/subtract with carry, small stack. Paged architecture becomes a real pain on larger projetcs, although the PIC18 architecture addresses (pun intended!) many of the issues.

Clocks etc.
Wider range of RC oscillator speeds. PLL high-frequency IO clock on some parts for high-speed captre etc.

More instructions per oscillator clock, but as most instructions take 2 cycles, and more instructions are often necessary for IO intensive tasks, this advantage is 2:1 at best. Most embedded apps are not especially throughput-dependent. Also, crystals and resonators get bigger and harder to get much below about 3MHz, so the speed advantage over a 4MHz PIC can often not be a major issue.  

Watchdog can be turned off by software.

Power consumption
Brownout detector on recent parts has much lower consumption than the PIC one, which is often useless for battery-powered apps.

UART
TX and RX can be enabled seperately - useful for multi-processor comms on a common bus. High baudrates are possible from low clock frequencies.

Interrupts
Vectored interrupts are more efficient where there are multiple interrupt sources, and registers can be reserved for interrupt-only use to speed up context save for low latency,

ADC
Some parts have differential inputs and a x20 gain amp, although the latter is so noisy (on the tiny26 at least) it reduces effective number of bits to 8.
Internal voltage reference - accuracy not great but often useful, even if only for measuring battery voltage.

I/O
Seperate PORT and PIN registers avoid read-modify-write issues with capacitively loaded pins. (Although has any AVR user never spent time wondering why their input port isn't working because they used PORTx instead of PINx...? ).

Devtools, programming, production etc.
JTAG-ICE Mk.II is really fast and very like a real ICE! Debugwire looks very interesting, using the reset pin only. PIC in-circuit debugger uses 2 pins, (however the large variety of PICs available means there is usually another part you can use for debugging).

And the winner is.....

If you've read the above, you'll have realised that the answer is Neither of course, it all depends on what your requirements are.
If you don't fully understand what you are trying to acheive, you shouldn't even be thinking about what chip to use yet. 

Coming next.... which is the best religion ;-)