AVR vrs PIC (I don't care)

uC is microController

Today I found a member on chat spouting the old news that for a given crystal speed a AVR will run 4 times faster than a PIC. Thus AVRs are better.

There is much more to selecting a processor then this and yes we have been down this road how many times? Regardless of which vendor you pick it is important to select the uC best matched to your project. Generally all the uC brands out there will do the job provided you pick one with the right resources.

For the person new to uC's by far the two most important issues are 'what the guy teaching or helping you is using' and 'the tools you have on hand'. The rest is near noise level.

Tell you what 3V0.... This thread could be a REAL hornets nest!!!

I'll watch with baited breath!!

I like to work with AVRs only because avr-gcc and avr-libc are well documented. I have read the documentation of some C compilers for PIC.. they are crap.

Yes.. Some compilers! The same could be said for compilers for any chip...

The C18 documentation is very admirable... and that same documentation has been moved over to the newer XC8...

3v0 said:

for a given crystal speed a AVR will run 4 times faster than a PIC.

Click to expand...

That is a good topic for debate practice. Just like ASM vs. C.
If you run out of computing power, do not blame the language or the chip. Just blame yourself for choosing the wrong chip and the wrong tools for the job.

For the person new to uC's by far the two most important issues are 'what the guy teaching or helping you is using' and 'the tools you have on hand'. The rest is near noise level.

Click to expand...

True... When at a college or UNI, students are co-hearsed onto a platform, not intentionally but because of the tools available.... Portsmouth EE courses are vastly sponsored by Phillips.... Hence my background in P89c51 and the XA51 processors... Since in the real world, I have dabbled in Rockwell, Hitachi (Renesas), and Microchip... I have a preference to microchip.... Not because they are a better chip, because the support is phenomenal... Almost everywhere you go today someone has done what you need to do on a pic... The support for the 8051 is vast, but the options are limited.. Unless you move to a TI device and then need their support software to program the chip...

The only experience I have with AVR is on the Arduino... The platform that lets anyone, with little or no programming experience, into the programming world... While I think this is a good starting position, it doesn't teach much low level micro hardware knowledge... You don't need a datasheet, therefore when you need to make your own shield you find you have learnt nothing...

As for the right tool for the job... No-one can argue that as they can all be used in a similar fashion... AVR and pic are going to be similar as they are fighting for the same market.. But to say one platform is better than another, well that's a blinkered view to be sure...

Ian Rogers said:

Arduino...

Click to expand...

It is funny (not) how arduino is trying to make things easy, but now people are failing to read any documentation.. it is a shame.. or maybe it is good for us. More jobs for us.. more jobs for the people who actually can read datasheets.

misterT said:

If you run out of computing power, do not blame the language or the chip. Just blame yourself for choosing the wrong chip and the wrong tools for the job.

Click to expand...

I suppose it would not take long to a professional to correct this during the development. But about the tools I think it is more difficult...

atferrari said:

I suppose it would not take long to a professional to correct this during the development. But about the tools I think it is more difficult...

Click to expand...

Well. If not going into merky details, C can be described on 20 pages. Compare this to the amount of documentation you need to read and understand to migrate from PICs to Cortex-M4 based MCUs (or in the other direction).

Microchip has such a vast selection of uC's in 8, 16, and 32 bits. Each can be had with several levels of memories and many mixes of a large selection of peripherals.

One has to work hard to get caught with the wrong chip and no easy path to the right one.

Doing basic "DSP" work, AVR and 18F are much of a muchness. 8 bit PICs generally run slower, but they do multiplications in one cycle over 2 in the AVRs (from memory). So why the arguments? It is like racing snails!

The age old theory of using the best tool that are you comfortable with for the job seems rather apt. I use AVRs now due to licensing (i.e. the free compilers) but I must comment that the PIC documentation and support is many orders of magnitude better.

Just wanted to post this

Dave is a PIC fanboy

misterT said:

Dave is a PIC fanboy

Click to expand...

But he uses both frequently. He's probably only a PIC fanboy because that was the first processor he got his hands on. Same can be said of AVR fanboys.

As Dave said,

IT DOESN'T BLOODY WELL MATTER!

Click to expand...

That pretty much sums it up

misterT said:

Dave is a PIC fanboy

Click to expand...

No he said exactly what I did.
AVR vrs PIC (I don't care)

My favorite processor is the one I used last because I am up to speed on it. Since I stopped working professionally it has been all PICs for two reasons.

If I were to do a design for production I would not limit myself to PICs. As Dave said you need to do the legwork and select the best chip for the job. Based on the current/local definition of best.

misterT said:

Dave is a PIC fanboy

Click to expand...

Take Dave's rant and edit "AVR" and "PIC" and swap the two words. It is still true.

IT DOESN'T BLOODY WELL MATTER!

Click to expand...

3v0 said:

uC is microController

Today I found a member on chat spouting the old news that for a given crystal speed a AVR will run 4 times faster than a PIC. Thus AVRs are better.

There is much more to selecting a processor then this and yes we have been down this road how many times? Regardless of which vendor you pick it is important to select the uC best matched to your project. Generally all the uC brands out there will do the job provided you pick one with the right resources.

For the person new to uC's by far the two most important issues are 'what the guy teaching or helping you is using' and 'the tools you have on hand'. The rest is near noise level.

Click to expand...

Love how you bring chat out to print.

DerStrom8 said:

But he uses both frequently. He's probably only a PIC fanboy because that was the first processor he got his hands on. Same can be said of AVR fanboys.

Click to expand...

I didn't mean to say "Dave is a PIC fanboy" in a bad way. I think everybody is a fan of something. I started out with PICs, but soon found out that practically nobody in my university used them. Everybody was using AVRs. Now I use AVRs because I have plenty of them at hand. I have some PICs, but I do not really have any proper tools to work with them at home. And I don't have any compilers installed for them.. so AVR it is.

I don't think there is much point for a hobbyist to equally use many different brands.. or invest money for many different kinds of programmers etc. If you learn one microcontroller, there is no problem quickly learning another one when you need to.

If it has not been said already, I think that it boils down to this:

Will the chosen micro do the job? Y/N

Do you have the tools for the chosen micro? Y/N

Are you familiar with the chosen micro? Y/N

If you get three Ys, you have cracked it, be happy, irrespective if the micro is a PIC, AVR or an 8080

There is a thought, if you had an old micro development board sitting in the corner of the lab, unused and unloved, and it had all the facilities you needed for a one off project, why not use it?
If the project is for "in house " use, not for sale to a customer.
If it is a one off and will not be duplicated.
If all the tools are available.
If someone if available who is familar with the old technology and can get it up and running with the minimum of fuss.
Why not use it?

JimB

I couldn't have said it better myself, JimB