Searching \ for 'why do you prefer PIC over AVR?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'why do you prefer PIC over AVR?'.

Truncated match.
PICList Thread
'why do you prefer PIC over AVR?'
2009\03\19@083918 by Yan Falken

flavicon
face
Hi - what are the reasons to use AVR instead of PIC and vice versa and
for which scenario would you use PIC and AVR? :) I'm a beginner and I'm still
not sure about these things.

Thanks

YF

2009\03\19@090545 by Russell McMahon

face
flavicon
face
> Hi - what are the reasons to use AVR instead of PIC and vice versa and
> for which scenario would you use PIC and AVR? :) I'm a beginner and I'm
> still
> not sure about these things.

This can rapidly become a religious discussion.
Both have their good points.

Here are a few starters for others to contradict :-).

PIC (Microchip) is extremely good at maintaining old versions - you can
still buy parts which were essentially obsolete or obsolescent years ago.
AVR tend to discontinue old processors quite quickly and while they provide
upgrade paths and some ideas aboutvhow to convert code, this means that
legacy code will very possibly not run without rewriting. The Microchip
policy is by far the most user friendly.

Microchip are reasonably good and friendly at with development hardware and
baseic development IDE. Others can talk about high level language support.

There was a time when Microchip devices had decidely strange architectures
that needed you to work harder to produce good code - thge end result was
quite efficient but you needed to be closer to guru status to get excellent
results. AVR started with a "more modern" architecture and for some while
were easier for beginners to produce reasonable results with. In recent
years Microchip have progressed their designs at an amazing rate and now
have 'modern' architectures and a wide range of good performance devices. To
their credit, you can STILL buy the olkd strange but efficient devices if
you need them.





   Russell

2009\03\19@092549 by Mauricio Giovagnini

flavicon
face
Yan Falken escribió:
> Hi - what are the reasons to use AVR instead of PIC and vice versa and
> for which scenario would you use PIC and AVR? :) I'm a beginner and I'm still
> not sure about these things.
>
> Thanks
>
> YF

I've not used AVR but what I heard from some colleagues were
always good things.

PICs are good too so I think the decission lies more on what
is your background knowledge about both families.

I've always used PICs so, migrating my designs and code to
an AVR will be time consuming and what for? Every feature I
needed was present on a PIC, on a smaller or on a bigger,
but it was there.

If we talk about costs.. pics are very competitive and even
if an AVR is cheaper than the equivalent PIC , the
development costs of learning a new environment, probably
buying some tools, etc... will be more probably bigger than
the savings.

So, my answer is both are good (of course depends on which
pic you choose) and your choice will be more probably
related to your own knowledge about the field, or your
partners knowledge about some specific devices.  If you work
on a team it is probable that the device chosen will be a
trade-off between the knowledge of the team , the
development time, the code present in your company for doing
the task, etc.

If you are an entrepeneur or a beginner that works alone..
then both choices are good, both have huge communities
behind them so you won't be alone on any case.

It reminds me when the question is "which is better
chevrolet or ford?" , "audi , mercedes benz or bmw?" =).  If
you live in a small city you will probably choose the car
that has good support close to your home, or the one that
uses your friend. =)


Regards




--
------------------------------
Mauricio Giovagnini (Maunix)
http://www.maunix.com.ar
Cordoba, Arg.
LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini

2009\03\19@093445 by Tamas Rudnai

face picon face
Just some thoughts about the 8 bit devices popped into my mind:

AVR pro:
- free gnu C compiler
- somewhat faster core
- enhanced instruction set in 8 pin package with RTOS and HLL support
- vector based interrupt system

AVR con:
- less availability than PIC
- assembly language is a bit difficult with confusing I/O, Register and RAM
address space
- debugging seems to be a bit painful with the free debug tools, especially
in terms of regression tests

PIC pro:
- robust silicon
- tremendous amount of documentation - even from the manufacturer
- easy and clear hw architecture
- wide variety of hw modules
- great choice of PIC devices for variety of projects
- very good simulator with advanced features from the manufacturer which is
even free of charge
- reliably manufacturing - seems to be better for long term and higher
quantity projects

PIC cons:
- C compilers are not free - or more precisely the free ones are limited to
program memory space and/or optimizasions
- core is a bit slower - if you need more computing speed you need to go for
16bit PICs
- there is no enhanced core for 8 pin package

Tamas


On Thu, Mar 19, 2009 at 12:36 PM, Yan Falken <spam_OUTseahawkTakeThisOuTspamvolny.cz> wrote:

> Hi - what are the reasons to use AVR instead of PIC and vice versa and
> for which scenario would you use PIC and AVR? :) I'm a beginner and I'm
> still
> not sure about these things.
>
> Thanks
>
> YF
> -

2009\03\20@135651 by Randy Glenn

flavicon
face
One area I vastly prefer PICs to AVRs is availability - Atmel parts
seem to disappear from the market just as you need them, with lead
times measured in months, not days. I've been trying to get a few
ATMEGA644P-20PUs for a couple months now with no joy as yet -
DigiKey's estimated ship date just got pushed back to the end of March
from the end of February. Microchip seems to have a better handle on
their supply chain.

The earlier mentioned problems with Atmel discontinuing parts quickly
is also a motivator - Atmel seems to want to keep the offerings
available to a minimum, whereas Microchip will sell a chip seemingly
for as long as anyone's willing to buy them. Very good if you don't
want to be re-qualifying a product every time the manufacturer decides
to upgrade.

I'm also falling in love with Peripheral Pin Select on the PIC24Fs.
UART, SPI, timer capture / compare can be routed to most any pin on
the device, VASTLY simplifying the board layout. That the 28-pin
device I'm using (PIC24FJ64GA002) has 2 I2C ports, 2 SPI Ports, 2
UARTs, 5 16-bit PWMs, a built-in Real-Time Clock and Calendar, and a
500 ksps ADC is very impressive for a device that small, I think.

So that's where I stand - I think both brands have their strengths and
weaknesses overall, but there are a few things I like better about
PICs. I'll generally use whichever I feel is most appropriate for the
application at hand.

-Randy

On Thu, Mar 19, 2009 at 8:36 AM, Yan Falken <.....seahawkKILLspamspam@spam@volny.cz> wrote:
> Hi - what are the reasons to use AVR instead of PIC and vice versa and
> for which scenario would you use PIC and AVR? :) I'm a beginner and I'm still
> not sure about these things.
>
> Thanks
>
> YF
> -

2009\03\20@142137 by solarwind

picon face
PICs are a whole lot cooler. I'm pretty sure they use a lot less
power, their assembly language seems to be easier, I love all the cool
C compilers out there, I like MPLAB, lots of different versions of
PICs, lots of onboard peripherals.

2009\03\20@161908 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf
{Quote hidden}

Always best to check your facts before making statements like this!

The AVR might have more instructions, but for serious applications I
would suspect it's easier to program in assembler.  That said I've only
ever written a few assembler modules for larger AVR projects, but have
written quite a bit of PIC assembly.  The 12 and 14 bit core is
certainly pretty simple, until you run into banking/paging problems...

If you are talking about commercial C compilers, the AVR also has plenty
of these, but just as with the PIC you'll need deep pockets for a
professional quality one.  However, the AVR has a rock solid port of
GCC, there is (very sadly) no equivalent compiler in the PIC world, i.e.
free, open source, unlimited, excellent optimisation and good support.
IMO SDCC has a bit of a chicken and egg problem, not enough users to
generate the interest required to improve it.  Perhaps things will
change with Microchips acquisition of HiTech.

Ultra low power AVR's are also available, e.g. Mega165 which has a
current consumption of around 100nA in it's power down state.

AVR Studio is the MPLAB equivalent for the AVR.  It's pretty good for
debugging stuff, but I don't like IDE's much generally since most people
have their own favourite editor, and using a makefile means improved
portability.

I will grant you that Microchip do have an enormous range of parts, and
are generally very good about maintaining availability of older ones, or
at least very close equivalents.  They also have the free sample
program, though I'm sure that can't possibly be swaying your opinion...

AVR's also have lots of on board peripherals.  Since you have apparently
never even looked at an AVR datasheet, let alone use one, I have to say
that you are probably not the most qualified person to make an impartial
comparison.

One area the PIC beats the AVR hands down is this list, which is (or at
least was until recently) far better than the AVRFreaks forum.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\21@205405 by Tamas Rudnai

face picon face
On Fri, Mar 20, 2009 at 8:19 PM, Michael Rigby-Jones <
EraseMEMichael.Rigby-Jonesspam_OUTspamTakeThisOuTbookham.com> wrote:

> The 12 and 14 bit core is
> certainly pretty simple, until you run into banking/paging problems...
>

In the other hand AVR suffers from the different address spaces problem.
While with PIC all the IO, SFR and GPR are on the same address space on AVR
they have 3 different one and the offsets are even changes when using this
or that instructions. Also as you cannot make arithmetical and logical
operation on a RAM element you need to read it first, make the operation on
it and the writing it back. Similar to this as you cannot make these
operation as one single instruction you loose the 'skip instruction'
facilities, you need to branch. So overall the "4 times faster than PIC with
the same clock" is not true - it is certainly faster but not 4 times.

My experience with AVR is that in the AVRstudio, the simulator is looks
nicer than anything useful for more than single stepping and learning AVR
assembly. It is slow - avr-gdb is faster but still not much of use of it.
Oshonsoft's simulator is slow on PIC so I did not even have a go with the
AVR - might be faster on AVR than that. Proteus is quite fast, but again, as
far as I know it does not have a stimulus file facilities either - correct
me if I am wrong. As the stimulus file option is missing, it is pretty hard
(if not impossible) to make regression tests. So even if you are using the
debugger on JTAG to increase the speed of testing the firmware, it is hard
to get similar functionalities as MPLAB has.

With AVR there is a big disadvantage for the beginners/hobbyists that one
can 'locked out' from icsp programming by setting a wrong config fuses. then
you either have to throw that chip away or build some external circuit (as
far as I remember some problem can be solved by an external clock, but there
is one where you need a parallel programmer to unlock the chip).

Also I found that for PIC there are way better and more number of
documentations, examples, tutorials than for AVR.
Other than that AVR is a nice device and the gcc support is a strong point
for choosing it over PIC.

Tamas
--
http://www.mcuhobby.com

2009\03\22@212134 by William \Chops\ Westfield

face picon face

On Mar 21, 2009, at 5:53 PM, Tamas Rudnai wrote:

> In the other hand AVR suffers from the different address spaces  
> problem. While with PIC all the IO, SFR and GPR are on the same  
> address space on AVR they have 3 different one and the offsets are  
> even changes when using this or that instructions.

What's the address space of "W" on PICs?   Actually, the AVR has a  
single address space that includes the registers (0-0x20), IO space  
(0x21-0x5F), extended IO space (0x5F-<chipdependent>), and RAM  
(<chipdependent>-0xFFFF)  Then they have a bunch of instructions that  
access small subsets of the address space in smaller formats (ie "set  
bit in IO reg" access 0x21-0x40 of IO space (as 0-31), IN and OUT  
access 0x21-0x5F (0-63) and of course the various register instructions.

OTOH, for an architecture claiming "general purpose registers", there  
are an awful lot of special cases. :-(

> Also as you cannot make arithmetical and logical operation on a RAM  
> element you need to read it first, make the operation on it and the  
> writing it back.

Which is a bit ambiguous give that there are at least 16 registers on  
AVR that act like W on PIC.  By some evaluations, the PICs don't have  
"RAM" as the word is used in AVR-land; they just have an extended set  
of registers.

What it amounts to is that the PIC is an "accumulator based"  
architecture extended with a bunch of operations that work directly on  
memory (including IO space), while the AVR is a multiple-register  
based machine with some exceptions.  I find the AVR architecture  
generally more "pleasant" to use in assembler, but it in now way  
reaches the heights of elegance of (say) a PDP-11 or PDP-10...

BillW

2009\03\23@020613 by Rikard Bosnjakovic

picon face
On Mon, Mar 23, 2009 at 02:21, William "Chops" Westfield <westfwspamspam_OUTmac.com> wrote:

> What's the address space of "W" on PICs?

I'm not sure I understand your question, but W (or WREG) is an 8-bit
working register in the cpu, used for ALU operations. It is not an
addressable register, and therefore it does not matter which memory
bank you are in - you can always access it.


--
- Rikard - http://bos.hack.org/cv/

2009\03\23@020822 by Rikard Bosnjakovic

picon face
On Mon, Mar 23, 2009 at 07:06, Rikard Bosnjakovic
<@spam@rikard.bosnjakovicKILLspamspamgmail.com> wrote:

> but W (or WREG) is an 8-bit working register in the cpu

Clarification: it's 8-bit on low- and mid-range PIC:s. I haven't
worked with high-end so I can't say anything about it for PIC18 and
higher, but it's probably bigger than 8-bit there.



--
- Rikard - http://bos.hack.org/cv/

2009\03\23@100135 by Tamas Rudnai

face picon face
On Mon, Mar 23, 2009 at 1:21 AM, William "Chops" Westfield
<KILLspamwestfwKILLspamspammac.com>wrote:

>   Actually, the AVR has a
> single address space that includes the registers (0-0x20), IO space
> (0x21-0x5F), extended IO space (0x5F-<chipdependent>), and RAM
> (<chipdependent>-0xFFFF)  Then they have a bunch of instructions that
> access small subsets of the address space in smaller formats (ie "set
> bit in IO reg" access 0x21-0x40 of IO space (as 0-31), IN and OUT
> access 0x21-0x5F (0-63) and of course the various register instructions.


Exactly. That is a bit confusing me, maybe that's because of my limited
brain :-)


> Which is a bit ambiguous give that there are at least 16 registers on
> AVR that act like W on PIC.


Well, there is a bit of difference here. On PIC you are making an operation
on W and Reg, on AVR you do a W on W operation if you are thinking in that
way. So on a non-volatile storage you still need to move back the results.
However, I agree that you can make nice optimizations keeping frequently
used values on registers. But it is quite the same on PIC: you can make
quite nice optimizations on the banking if you organise the data/code in a
way that you need limited number of bank selection.

Anyway, AVR is a newer architecture and probably better than PIC, and I do
like many of the things on it like the vector based interrupt system and the
enhanced instruction set, however, until AVR is harder to rely on in terms
of supply and long term support, I will stick to the PIC.

Tamas

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...