> I come from a background of Basic Stamps and want to get into some
> more
> advanced microcontrollers. I am having a terrible time trying to find
> some
> comprehensive comparisons of AVR technologies vs. the PIC. I want to
> make
> sure I make the right choice before investing time or money into one
> or
> the other.
>
> I have searched the archives and just get unrelated search results but
> I
> am sure this topic has come up before. Can anyone steer me in the
> right
> direction?
>
> - Matt

>I come from a background of Basic Stamps and want to get into some more
>advanced microcontrollers. I am having a terrible time trying to find some
>comprehensive comparisons of AVR technologies vs. the PIC. I want to make
>sure I make the right choice before investing time or money into one or
>the other.
>
>I have searched the archives and just get unrelated search results but I
>am sure this topic has come up before. Can anyone steer me in the right
>direction?
>
>- Matt
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.
>
>
>
>
>
>
>

> -----Original Message-----
> From: pic microcontroller discussion list
> [spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU]On Behalf Of M. Adam Davis
> Sent: Thursday, 12 September 2002 1:58 AM
> To: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU
> Subject: Re: [PIC][AVR]: Cant find info on AVR vs. PIC Please help.
>
>
> I don't recall a really definitive document that covers all the ins and
> outs.
>
> Some of the basic differences are (not including atmega or arm thumb,
> since they are fundamentally different):
> PIC takes four clock cycles to execute one instruction (18 has PLL so
> one external clock cycle will execute one instruction now), most go to
> 20MHz and do 5mips, 18 series with pll go to 40MHz and can do 10mips.
> AVR does one instruction per cycle, but generally doesn't go above 12MHz
> - therefore 12mips.
>
> PIC has, by today's standards, an odd instruction set partly due to its
> design, partly due to backwards compatability.  Many people coming from
> another uC or uP have some difficulty remembering the quirks of the code
> until they get used to it.
> AVR is essentially an 8051 core and has what many consider to be an
> industry standard instructon set.

> PIC includes both eprom (non-eraseable) and flash chips in their line.
> AVR is all flash.
>
> PIC's manufacturer, Microchip, has a very small focus.  They do
> controllers, and some analog, and some memory.  They are branching out
> into other areas, but have kept to fairly simple straightforward
> products.  They own their own fab (fabs?  I think they just purchased
> another recently...) and are using older, cheaper processes to control
> costs.
> AVR's manufacturer, ATMEL, has a fairly broad focus.  Their flash memory
> business, IIRC, outsells their microcontroller business.  The AVR has
> become unavailable for short periods of time to the small quantity
> market because their fabs are producing flash which was being sold
> faster than they could make it, and the controllers they did have were
> promised to larger manufacturers, not hobby channels.  I've heard this
> is largely resolved, but that could simply be because other
> manufacturers started pumping out the flash.  In other words the
> fundamental problem may still remain, but could be hiding.



> Microchip tends to announce future products a year or two before they
> become available to hobbiests.  When their website says that something
> is 'in production' it may still take another 6 months for suppliers to
> stock it.
> Atmel - I am not familier with their marketting strategy.
>
> Microchip documentation is one of the best available, hands down.  There
> are still minor issues, and as their product line grows their
> documentation has seemed to become less well maintained (for instance,
> there are still charts marked 'preliminary' on the final f8xx datasheet
> several years after it became available to the hobbiest market!)  There
> are a few tables (notably the SPBRG tables) which are incorrect.  Since
> the processors are similar large sections are copied from one generation
> to the next.  So far I've never found an innaccuracy in the text and
> formulas, but some tables are suspect.  The documentation is reasonably
> complete (large) and the only item they've left out which is useful is
> the debugging registers and vector.  For the f8xx series this is in
> another document.  No one has found them for the 18 series though.
> Atmel documentation is standard in the industry, and I've found is not
> as complete as Microchip's.

> Microchip seems to have done a lot of work on application notes, there
> are not as many notes for atmel's processors.
>
> There still is no free C compiler for the PIC line.  Scott Dattallo is
> working on porting the small device c compiler to the midrange (16
> series), but it won't be very helpful for the high end (18) or low end
> (12, 14, 15).  There are several packages that are inexpensive by
> industry standards (c2c, ccs, hitech, cc5x) and one which is free for
> non commercial use up to 1k of instructions(cc5x).  None of them provide
> one compiler for all pics, instead deviding it up into two or more sets
> (low and midrange 12-16, 17, 18) and I suspect the DSPic will require a
> different compiler as well.
> The GCC compiler has been ported to the AVR and is freely available.
>  Because of this there are few other AVR compilers, and those that do
> exist are high performance (and high cost).  Part of the reason for the
> compiler availability is that the AVR is so similar to the 8051, for
> which existed a GCC port, and the standard instruction set which was
> well suited to the C language.  The PIC is rather ill-suited to the C
> language and there are lots of nasty hacks to make it work well.
>
> The only other metric which I suspect has any bearing on your decision
> is the code space available in eithe chip.  A quick peek shows that the
> avr has up to 8k of code space - just remember that each instruction
> (IIRC) takes two bytes.  The PIC typically lists code space in two ways,
> one in KB, the other in number of instructions. (so a 16KB 18f pic holds
> 8k of instructions).
>
> The atmega is a valid AVR as well, and you should take that into
> account.  It appears that the speed on some AVRs is 16MHz, which is
> still 50% faster than the fastest pic.  Like Intel and AMD you can't
> compare them on clock speed alone, but the clock speed is still a fairly
> good indication of possible performance.

>
>
>
> > PIC has a large set of  products with many various peripherals, nearly
> > all of which are available to hobbiests in ones and twos for low costs
> > from 'regular' hobby sources.
> > AVR has a small set of devices with normal peripherals, their line is
> > not completely represented by 'regular' hobby sources but you can
> > usually still buy low quantities of the less common controllers from
> > Arrow and the larger industry sources.  Lead time can be more an issue
> > with atmel, but costs can be lower as well.
>
> Never had a problem with sourcing the AVR's, The 89C51 /2 deffinately, but
> there are other sources eg other ppl who use them, IE in AU Grantronics in
> Sydney has a good supply.
>
>
> > PIC includes both eprom (non-eraseable) and flash chips in their line.
> > AVR is all flash.
> >
> > PIC's manufacturer, Microchip, has a very small focus.  They do
> > controllers, and some analog, and some memory.  They are branching out
> > into other areas, but have kept to fairly simple straightforward
> > products.  They own their own fab (fabs?  I think they just purchased
> > another recently...) and are using older, cheaper processes to control
> > costs.
> > AVR's manufacturer, ATMEL, has a fairly broad focus.  Their flash memory
> > business, IIRC, outsells their microcontroller business.  The AVR has
> > become unavailable for short periods of time to the small quantity
> > market because their fabs are producing flash which was being sold
> > faster than they could make it, and the controllers they did have were
> > promised to larger manufacturers, not hobby channels.  I've heard this
> > is largely resolved, but that could simply be because other
> > manufacturers started pumping out the flash.  In other words the
> > fundamental problem may still remain, but could be hiding.
>
>
>
> > Microchip tends to announce future products a year or two before they
> > become available to hobbiests.  When their website says that something
> > is 'in production' it may still take another 6 months for suppliers to
> > stock it.
> > Atmel - I am not familier with their marketting strategy.
> >
> > Microchip documentation is one of the best available, hands down.  There
> > are still minor issues, and as their product line grows their
> > documentation has seemed to become less well maintained (for instance,
> > there are still charts marked 'preliminary' on the final f8xx datasheet
> > several years after it became available to the hobbiest market!)  There
> > are a few tables (notably the SPBRG tables) which are incorrect.  Since
> > the processors are similar large sections are copied from one generation
> > to the next.  So far I've never found an innaccuracy in the text and
> > formulas, but some tables are suspect.  The documentation is reasonably
> > complete (large) and the only item they've left out which is useful is
> > the debugging registers and vector.  For the f8xx series this is in
> > another document.  No one has found them for the 18 series though.
> > Atmel documentation is standard in the industry, and I've found is not
> > as complete as Microchip's.
>
> The AVR data sheets are better than most, the app notes are great (and
> AVRfreaks have a fair few "home grown" app notes being generated by

> design note compertitions).
>
>
> > Microchip seems to have done a lot of work on application notes, there
> > are not as many notes for atmel's processors.
> >
> > There still is no free C compiler for the PIC line.  Scott Dattallo is
> > working on porting the small device c compiler to the midrange (16
> > series), but it won't be very helpful for the high end (18) or low end
> > (12, 14, 15).  There are several packages that are inexpensive by
> > industry standards (c2c, ccs, hitech, cc5x) and one which is free for
> > non commercial use up to 1k of instructions(cc5x).  None of them provide
> > one compiler for all pics, instead deviding it up into two or more sets
> > (low and midrange 12-16, 17, 18) and I suspect the DSPic will require a
> > different compiler as well.
> > The GCC compiler has been ported to the AVR and is freely available.
> >  Because of this there are few other AVR compilers, and those that do
> > exist are high performance (and high cost).  Part of the reason for the
> > compiler availability is that the AVR is so similar to the 8051, for
> > which existed a GCC port, and the standard instruction set which was
> > well suited to the C language.  The PIC is rather ill-suited to the C
> > language and there are lots of nasty hacks to make it work well.
> >
> > The only other metric which I suspect has any bearing on your decision
> > is the code space available in eithe chip.  A quick peek shows that the
> > avr has up to 8k of code space - just remember that each instruction
> > (IIRC) takes two bytes.  The PIC typically lists code space in two ways,
> > one in KB, the other in number of instructions. (so a 16KB 18f pic holds
> > 8k of instructions).
> >
> > The atmega is a valid AVR as well, and you should take that into
> > account.  It appears that the speed on some AVRs is 16MHz, which is
> > still 50% faster than the fastest pic.  Like Intel and AMD you can't
> > compare them on clock speed alone, but the clock speed is still a fairly
> > good indication of possible performance.
>
> The "standard" AVR is like talking on Pic 12 and 15 (and low end 16)

> older technology. The Newer AVR's are they Tiny's and Mega's. The Mega128
> (as an example) has a clock speed of 16Mhz and aproches 16Mips.
>
>
> > What this all boils down to is it pretty much doesn't matter.  You can
> > buy chips for both and wire up simple parallel port programmers, use the
> > free assemblers from both and try them both out for under $20.  Go to
> > the AVR list and see what kind of comparison they make.  In the end you
> > ought to choose one that has the support system you need.
>
> If you go to my website it has the schematics for the "elcheapo"

> one design works well on a PIC, another works better on an AVR.
>
>
> > -Adam
> Regards,
>
> Kat.
>
> **********************************************
> K.A.Q. Electronics.
> Electronic and Software Engineering.
> Perth, Western Australia.
> Ph +61 (0) 419 923 731
> **********************************************
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.386 / Virus Database: 218 - Release Date: 9/09/2002
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>
>

> I don't recall a really definitive document that covers all the ins and
> outs.
>
> Some of the basic differences are (not including atmega or arm thumb,
> since they are fundamentally different):
> PIC takes four clock cycles to execute one instruction (18 has PLL so
> one external clock cycle will execute one instruction now), most go to
> 20MHz and do 5mips, 18 series with pll go to 40MHz and can do 10mips.
> AVR does one instruction per cycle, but generally doesn't go above 12MHz
> - therefore 12mips.
>
> PIC has, by today's standards, an odd instruction set partly due to its
> design, partly due to backwards compatability.  Many people coming from
> another uC or uP have some difficulty remembering the quirks of the code
> until they get used to it.
> AVR is essentially an 8051 core and has what many consider to be an
> industry standard instructon set.
>
> PIC has a large set of  products with many various peripherals, nearly
> all of which are available to hobbiests in ones and twos for low costs
> from 'regular' hobby sources.
> AVR has a small set of devices with normal peripherals, their line is
> not completely represented by 'regular' hobby sources but you can
> usually still buy low quantities of the less common controllers from
> Arrow and the larger industry sources.  Lead time can be more an issue
> with atmel, but costs can be lower as well.
>
> PIC includes both eprom (non-eraseable) and flash chips in their line.
> AVR is all flash.
>
> PIC's manufacturer, Microchip, has a very small focus.  They do
> controllers, and some analog, and some memory.  They are branching out
> into other areas, but have kept to fairly simple straightforward
> products.  They own their own fab (fabs?  I think they just purchased
> another recently...) and are using older, cheaper processes to control
> costs.
> AVR's manufacturer, ATMEL, has a fairly broad focus.  Their flash memory
> business, IIRC, outsells their microcontroller business.  The AVR has
> become unavailable for short periods of time to the small quantity
> market because their fabs are producing flash which was being sold
> faster than they could make it, and the controllers they did have were
> promised to larger manufacturers, not hobby channels.  I've heard this
> is largely resolved, but that could simply be because other
> manufacturers started pumping out the flash.  In other words the
> fundamental problem may still remain, but could be hiding.
>
> Microchip tends to announce future products a year or two before they
> become available to hobbiests.  When their website says that something
> is 'in production' it may still take another 6 months for suppliers to
> stock it.
> Atmel - I am not familier with their marketting strategy.
>
> Microchip documentation is one of the best available, hands down.  There
> are still minor issues, and as their product line grows their
> documentation has seemed to become less well maintained (for instance,
> there are still charts marked 'preliminary' on the final f8xx datasheet
> several years after it became available to the hobbiest market!)  There
> are a few tables (notably the SPBRG tables) which are incorrect.  Since
> the processors are similar large sections are copied from one generation
> to the next.  So far I've never found an innaccuracy in the text and
> formulas, but some tables are suspect.  The documentation is reasonably
> complete (large) and the only item they've left out which is useful is
> the debugging registers and vector.  For the f8xx series this is in
> another document.  No one has found them for the 18 series though.
> Atmel documentation is standard in the industry, and I've found is not
> as complete as Microchip's.
>
> Microchip seems to have done a lot of work on application notes, there
> are not as many notes for atmel's processors.
>
> There still is no free C compiler for the PIC line.  Scott Dattallo is
> working on porting the small device c compiler to the midrange (16
> series), but it won't be very helpful for the high end (18) or low end
> (12, 14, 15).  There are several packages that are inexpensive by
> industry standards (c2c, ccs, hitech, cc5x) and one which is free for
> non commercial use up to 1k of instructions(cc5x).  None of them provide
> one compiler for all pics, instead deviding it up into two or more sets
> (low and midrange 12-16, 17, 18) and I suspect the DSPic will require a
> different compiler as well.
> The GCC compiler has been ported to the AVR and is freely available.
>  Because of this there are few other AVR compilers, and those that do
> exist are high performance (and high cost).  Part of the reason for the
> compiler availability is that the AVR is so similar to the 8051, for
> which existed a GCC port, and the standard instruction set which was
> well suited to the C language.  The PIC is rather ill-suited to the C
> language and there are lots of nasty hacks to make it work well.
>
> The only other metric which I suspect has any bearing on your decision
> is the code space available in eithe chip.  A quick peek shows that the
> avr has up to 8k of code space - just remember that each instruction
> (IIRC) takes two bytes.  The PIC typically lists code space in two ways,
> one in KB, the other in number of instructions. (so a 16KB 18f pic holds
> 8k of instructions).
>
> The atmega is a valid AVR as well, and you should take that into
> account.  It appears that the speed on some AVRs is 16MHz, which is
> still 50% faster than the fastest pic.  Like Intel and AMD you can't
> compare them on clock speed alone, but the clock speed is still a fairly
> good indication of possible performance.
>
> What this all boils down to is it pretty much doesn't matter.  You can
> buy chips for both and wire up simple parallel port programmers, use the
> free assemblers from both and try them both out for under $20.  Go to
> the AVR list and see what kind of comparison they make.  In the end you
> ought to choose one that has the support system you need.
>
> -Adam
>
> Matt Johnson wrote:
>
> >I come from a background of Basic Stamps and want to get into some more
> >advanced microcontrollers. I am having a terrible time trying to find some
> >comprehensive comparisons of AVR technologies vs. the PIC. I want to make
> >sure I make the right choice before investing time or money into one or
> >the other.
> >
> >I have searched the archives and just get unrelated search results but I
> >am sure this topic has come up before. Can anyone steer me in the right
> >direction?
> >
> >- Matt
> >
> >--
> >http://www.piclist.com hint: The PICList is archived three different
> >ways.  See http://www.piclist.com/#archives for details.
> >
> >
> >
> >
> >
> >
> >
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>
>

>>There still is no free C compiler for the PIC line.
>>
>>
>
>
>Not quite totally accurate. HiTech have available a free C compiler that
>does the 16F84 and 16F627. Can also be used with the 16F628, but the
>compiler is limited to the memory size of the 16F627.
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
>
>
>
>
>
>
>