pic or avr microcontrollers?

[rickselectricalprojects]

hi everyone!
i am sorry if there is already a poll for this but i couldn't find one so i decided to do one.
i am only asking to see (and for others to see) what is the most popular microcontroller . my guess is pic even though i like avr (sorry dave, i know you hate fanboys but i still use pic )
(P.S don't be to harsh because i am only 14 and i dont know everything)
thanks!

[Howardlong]

I have no experience in AVR (other than Arduino, but I don't count that) at all, but oodles in PIC, so inevitably I'm always going to use a PIC. Nothing wrong in AVR that I'm aware of, I just have enough in this head of mine already without having to deal with something else unnecessarily.

[nctnico]

I didn't vote because I hate both 
It's 2015: time to quit messing with 8 bit controllers.

[22swg]

rick...... If you follow threads here you will see there are underlying passions for various micros , its a kind of tribalism like in sport. The question 'most popular' means nothing , its like most beautiful.. as the saying goes '  its in the eye of the beholder '  I am getting on a bit in years so learning new stuff takes time and $$$ so I stick with what I think I know ...  good to see 14 year old exploring the mcu world .        

PS I didnt vote love / hate ? ,  I had some great fun with my first micro an RCA1802   

[Psi]

Whats that sound in the distance?
It's the trolls, they be coming.

[T3sl4co1l]

AVR has a much better instruction set (if still overly simple; it's a RISC machine), which makes assembly easier but not usually necessary, and C more-or-less effortless.  PIC-C is almost a contradiction; the underpinnings of C simply can't be supported in an easy, general sense on a PIC, so you end up with all sorts of bad restrictions.

The one not on the list, ARM, is a much wider architecture, vastly richer (to the point where even I wouldn't recommend writing assembly for it), ideally suited to C, and massively supported by pretty much all manufacturers.

Tim

[zapta]

For hobbyists, the AVR is more popular because of the arduino. If you want to pick one to learn, I would go with the Arduino for that reason.

[janoc]

hi everyone!
i am sorry if there is already a poll for this but i couldn't find one so i decided to do one.
i am only asking to see (and for others to see) what is the most popular microcontroller .

Most popular for what? And by what criteria? This has been rehashed many times already, just search the forum.

Also, why just PIC or AVR? Where is your XMega? Or the many ARMs that are displacing these 8bit controllers today? Or even the good old 8051 family ...

Poorly question gets you only equally poor answers.

[dannyf]

If I have to pick one of the two (AVR vs. PIC10/12/16/18), I would go with AVR, for speed, peripheral uniformity and ease of programming (vectored interrupt controller for example).

However, most of the time, your choice of mcu is influenced by other factors, like existing code base, tools availability, sourcing requirements, corporate policies, etc. The mcus themselves rarely come into play.

If I have to start today on mcu, I wouldn't pick any of them. I would consider PIC24 (if I am also new on coding), or one of the  ARM M0/M0+ chips (if I am more experienced in coding).

[diyaudio]

Microchip has one of the best datasheets, PIC24, dsPIC33 series nice, lots of peripherals and flash. lacks DMA though.

If you want to seriously challenge yourself and "move with the times" Go ARM, I just hate their vendor datasheets, all of them suck, so does their sample documentation. 

But hey, everything has a place and purpose.

[AndyC_772]

Last time I checked, Microchip had the best selector tool, which meant it was much easier to find the correct PIC for a given project than competitors' offerings. There are also some really nice analogue peripherals available in PICs, which make implementing circuits to which they're suited much easier and cheaper than they would be otherwise.

I had to use an AVR for a job last year and had nothing particularly against it, though. Atmel's free compiler is better than XC8, and IIRC the AVR architecture doesn't have the same silly problem whereby reads from Flash use different instructions than reads from RAM. You can pass a pointer to a function without having to care whether, say, a string is in a RAM buffer or is a constant in ROM.

If I don't need the analogue peripherals from the PIC world, then I'm tending to use STM32 these days instead.

[igendel]

Here's from a hobbyist with no formal background. I started with the Arduino and moved slowly to "bare" AVRs, then discovered cheap old PICs on ebay so I decided to give them a try too. While the AVRs do feel more modern and powerful, I find that I'm learning a lot abut MCUs in general simply from working with both kinds.

[Skimask]

I use these exclusively.

http://www.digikey.ca/product-detail/en/RM48L952ZWTT/296-35500-ND/3768427

I find my LEDs blink really good, I can do 10 at a time with this baby.
Anything else is so 20th century.

Do they ALL blink at the same time?
Or did you get them to blink independently?
 

[zapta]

... and IIRC the AVR architecture doesn't have the same silly problem whereby reads from Flash use different instructions than reads from RAM. You can pass a pointer to a function without having to care whether, say, a string is in a RAM buffer or is a constant in ROM.

I don't think this is correct. String literals in avr-gcc are copied at initialization time to RAM and can be a RAM hog, and if you leave it in flash only you read it differently than ram.

http://www.baldengineer.com/arduino-f-macro.html

BTW, I switched recently from avr to arm and found it to be simpler and more intuitive (e.g. consistent memory mapped access to ram, rom and i/o registers). You just write straight forward C/C++ and things work as expected.

[AndyC_772]

Ah, OK, so the compiler effectively hides the difference. That would indeed waste a lot of RAM

[Howardlong]

AVR has a much better instruction set (if still overly simple; it's a RISC machine), which makes assembly easier but not usually necessary, and C more-or-less effortless.  PIC-C is almost a contradiction; the underpinnings of C simply can't be supported in an easy, general sense on a PIC, so you end up with all sorts of bad restrictions..

Tim

Not sure if you're referring to the lower end PICs, such as PIC10, 12, 16 and 18? These do suffer due to the bank switching required which not only slows down code, it does as you say present limitations, although these days with XC8 it is largely hidden from the programmer, but of course it does sometimes generate unexpectedly slow code as a result of the continual bank switching.

The PIC24, dsPIC and PIC32 are are a completely different kettle of fish, far more Friendly when it comes to C, without the pesky bank switching nonsense.

[Howardlong]

Microchip has one of the best datasheets, PIC24, dsPIC33 series nice, lots of peripherals and flash. lacks DMA though.

While not all PIC24 and dsPICs have DMA, there are plenty that do. Not sure about the datasheets, except for the low end devices, you end up needing to refer to and cross reference a couple of dozen data sheets for a single device as they've split out generic functions from the main device datasheets. It's just a bit irritating having to juggle several documents concurrently.

If you want to seriously challenge yourself and "move with the times" Go ARM, I just hate their vendor datasheets, all of them suck, so does their sample documentation. 

I'd agree with that in general. NXP for example seem to have reticence in providing diagrams in their documentation. TI on the other hand have so much documentation it's difficult to know where to start.

[nctnico]

Regarding NXP's ARM controllers: Keil has the schematics of a multitude of development boards for NXP's ARM controllers on their website. Those are an excellent starting point.

[T3sl4co1l]

AVR has a much better instruction set (if still overly simple; it's a RISC machine), which makes assembly easier but not usually necessary, and C more-or-less effortless.  PIC-C is almost a contradiction; the underpinnings of C simply can't be supported in an easy, general sense on a PIC, so you end up with all sorts of bad restrictions..

Tim

Not sure if you're referring to the lower end PICs, such as PIC10, 12, 16 and 18? These do suffer due to the bank switching required which not only slows down code, it does as you say present limitations, although these days with XC8 it is largely hidden from the programmer, but of course it does sometimes generate unexpectedly slow code as a result of the continual bank switching.

The PIC24, dsPIC and PIC32 are are a completely different kettle of fish, far more Friendly when it comes to C, without the pesky bank switching nonsense.

Yes, they really shouldn't be called PICs because they're so much different and better.

I don't remember what PIC24 comes from, but PIC32 == MIPS, which is a mature 32 bit instruction set.  Example: the two big consoles in the late 90s (PlayStation and Nintendo 64) used a MIPS cores, offering capability comparable to your average 486 PC of the day (or, I'd say below average for the PS, but it was the cheaper option, wasn't it?).

I suppose the remaining question is: why choose PIC32 when ARM is broadly as capable, but more widely supported?

Alas, I haven't researched any of them well enough to have such an opinion, so I'll leave that to others better informed.

Tim

[nctnico]

Microchip probably choose MIPS because it was cheaper to license and/or they wanted to be different. The problem however is that if you are looking for assembly optimised code you can find it for ARM 999 out of 1000 times while for MIPS you'll find it 1 out of 1000 times. I have used a MIPS SoC in the past and choosing MIPS basically means saying goodbye to the civilised world and enter a deserted world where you are very much on your own. That is one of the main reasons you'll only find MIPS in high volume consumer equipment: the price of the final product isn't based on the engineering cost but on parts and IP licenses.

[Psi]

My thoughts on the differences are:

AVRs have more hardware peripherals packed into the mcus at a cost of a more expensive MCU and less range.
Microchip tend to have a wider range of pic mcus with a lot of hardware combinations so if you don't need x you can find a mcu version without it and save a few cents.

PICs are a bit slower clock for clock due to architecture. Instructions take a few clocks to execute vs AVRs which do most instructions in a single clock. This isn't a negative. You just use a faster xtal if you need to.

AVRs have a free compiler which is intergrated into free IDEs. Commercial projects are easy without having to check licenses.

PICs tend to have more silicon bugs than AVRs. Probably due to making so many mcu versions and varients.

AVRs have really nice hardware peripherals which are easy to understand and program. Some if the PIC hardware peripherals can be confusing.

[miceuz]

I'm new to pic and I've voted for AVR just because of the compiler. I like the low price and ability to select exactly what I need of PIC, but as I try to keep all my work open source, crippled and buggy XC8 is not a nice environment for OS project.

[rickselectricalprojects]

hi everyone!
i am sorry if there is already a poll for this but i couldn't find one so i decided to do one.
i am only asking to see (and for others to see) what is the most popular microcontroller .

Most popular for what? And by what criteria? This has been rehashed many times already, just search the forum.

Also, why just PIC or AVR? Where is your XMega? Or the many ARMs that are displacing these 8bit controllers today? Or even the good old 8051 family ...

Poorly question gets you only equally poor answers.

i just did avr vs pic because those are the most common two and there is alot of debate about which one of he two is better and the critera is just which one is prefered and used more by the people on the forum

[rickselectricalprojects]

Whats that sound in the distance?
It's the trolls, they be coming.

yea and also the "dickhead fanboys" as quoted by dave

[amyk]

i just did avr vs pic because those are the most common two and there is alot of debate about which one of he two is better and the critera is just which one is prefered and used more by the people on the forum

The most common 8-bit MCU would probably be 8051...

[Howardlong]

PICs are a bit slower clock for clock due to architecture. Instructions take a few clocks to execute vs AVRs which do most instructions in a single clock. This isn't a negative. You just use a faster xtal if you need to.

PIC10/12/16/18 Fcycle = 4 x Fxtal
PIC24/dsPIC Fcycle = 2 x Fxtal
PIC32 Fcycle = Fxtal

AVRs have a free compiler which is intergrated into free IDEs. Commercial projects are easy without having to check licenses.

As does Microchip, although if you want the full optimisation it's going to cost. Not sure how long this will last though, it's a competitive world out there.

PICs tend to have more silicon bugs than AVRs. Probably due to making so many mcu versions and varients.

I can't disagree with that, and it's not getting any better, the newest PIC32MZs are a disgrace.

AVRs have really nice hardware peripherals which are easy to understand and program. Some if the PIC hardware peripherals can be confusing.

You should try some of the NXP devices' peripherals, there's a lesson in self-flagellation!

[AndyC_772]

I'll see your NXP, and raise you an STM32 timer.

[ebclr]

None Of then STM32 cover both at less cost

[Psi]

STM32 timers are intended to be used with the standard library, so they didn't put much effort into making the registers human friendly

[nctnico]

Why not ARM? Screw people who say ARM microcontrollers are complicated! (where is the middle finger smiley  )
I started to get interested in microcontrollers when I was not much older than 14 and I would have given my left nut if something like a modern ARM controller was available back then. The sheer amount of processing power opens so much possibilities...

[BloodyCactus]

As does Microchip, although if you want the full optimisation it's going to cost. Not sure how long this will last though, it's a competitive world out there.

for pic32 its free, just recompile gcc without the license server check. since its open source, it is legal to do so.

[Howardlong]

As does Microchip, although if you want the full optimisation it's going to cost. Not sure how long this will last though, it's a competitive world out there.

for pic32 its free, just recompile gcc without the license server check. since its open source, it is legal to do so.

Interesting. The draconian licensing Microchip introduced about three years ago with their XC series of compilers sticks, it keeps breaking as it's tied to whatever MAC address the compiler picks up. particularly in these days of virtual NICs, it's all too easy to break that. I believe that more recently they've now also become time-limited, with annual subscription. I had previously been grandfathered in from the C18, C30 and C32 compilers which had no annual subscription and free updates. So if you want to use the new chips with the full optimizing compiler. you'd have to fork out for an annual subscription, one for each of the three compilers.

Again it is difficult to see how this can continue when other vendors are giving away their full compilers either gratis, or at a much reduced cost compared to Microchip.

[andersm]

Why not ARM? Screw people who say ARM microcontrollers are complicated!

Obviously YMMV, but apart from the clock setup, I really don't think eg. the STMF1 series is any more complicated than the ATmega series. And the vendor provides code for configuring the clocks.

[BloodyCactus]

Interesting. The draconian licensing Microchip introduced about three years ago with their XC series of compilers sticks, it keeps breaking as it's tied to whatever MAC address the compiler picks up. particularly in these days of virtual NICs, it's all too easy to break that. I believe that more recently they've now also become time-limited, with annual subscription. I had previously been grandfathered in from the C18, C30 and C32 compilers which had no annual subscription and free updates. So if you want to use the new chips with the full optimizing compiler. you'd have to fork out for an annual subscription, one for each of the three compilers.

well they provide the source for xc32 since it is gcc. your still stuck with licensing in xc8/xc16 etc but for xc32 you can just comment it out and recompile

[dannyf]

, it keeps breaking

I can report no problem here.

when other vendors are giving away their full compilers

Curious who those other vendors are.

But end of the day, if you are that sensitive to tool costs, maybe you aren't the ones Microchip wants to sell chips to - and I think they are right about that -> I have never encountered a commercial situation where costs of tools drive hardware decisions.

[nctnico]

, it keeps breaking

I can report no problem here.

That is short sighted. Imagine you are on a deadline and your PC breaks down. Transferring a license can take a lot of time especially if you can remove a license from a dead PC. As a rule I don't use software which requires a node locked license.

when other vendors are giving away their full compilers

Curious who those other vendors are.

But end of the day, if you are that sensitive to tool costs, maybe you aren't the ones Microchip wants to sell chips to - and I think they are right about that -> I have never encountered a commercial situation where costs of tools drive hardware decisions.

Work as an engineer in the Netherlands for a while. Tool costs are everything. Distributors are usually handing out the tools for free otherwise they won't sell any chips.

[westfw]

Atmel's avr-gcc is free and many other vendors are supporting both gcc and a for-money compiler (for certain definitions of "their" and "supporting.")

For PIC32 (or some PIC32s, anyway), you can think about downloading the "mpide" environment.  This is an arduino-clone IDE, which of course includes an appropriate copy of gcc for mips, newlib, and etc that can be used from cli or other IDEs. (available for three OSes; no compiling required.)  "They" have gone to some effort to avoid microchip-licensed libraries in favor of open source.

[Poe]

Now have a poll for who started on which platform.

I've found people identify with the first thing they fully learn.  Everything else is 'unintuitive'.

 

[dannyf]

I started with intel mcs-48.

I have to say, that I don't find any of the mcus I have worked on to be intuitive or un-intuitive: they are actually transparent to me for the most part. And I actually know very little about the inner workings of those chips, as I program in C.

To give you an example, my favorite development environment is CB+GCC and uVision C51. Most of the code I wrote run on ARM and PIC24 chips, but they might as well run on AVR or 8051 or you-name-it.