EEVblog #63 – Microchip PIC vs Atmel AVRPosted on February 22nd, 2010 121 comments
Let the microcontroller fanboy wars begin!
Dave’s rather random rant on which is better, Microchip PIC or Atmel AVR.
(Warning, Dave hates Fanboys)
this is funny to see angered avr fanboys arguing that they are not fanboys which just prove exactly opposite
I have worked for both companies. You started off great, there are definite trade offs. But it did not take long to figure out your a Fanboy.
do you guys think they will upgrade this product to a better one ?
Dude, your section on the compiler could be summed up into: “I used the latest Microchip tool, and in comparison with some ancient version of the Atmel tool it was better. I haven’t tried the newer one, but I bet it sucks.”. Who’s the fanboy again?
Thanks for the brilliant blogs, came across them when I was looking for an oscilloscope — DS1052E on its way. And I’ve learned an awful lot more about a lot more. Using up the gigabytes rather fast, and my wife wonders at the hoots of appreciative laughter
The only disappointment is your deprecation of assembly language programming. I agree it takes a lot of learning — I spent 25 years teaching it (and C and Cobol) to undergraduates. I like it because it gets me so close to, and really understanding, the guts of the machine, and, once you’ve got a library of routines, e.g. LCD drivers, it’s not as longwinded as it appears.
The real secret is good documentation, and plenty of it.
Best wishes, Harry
“Define the task, do your research and apply the microprocessor best suited to it.”
Must be why I have always looked in derision on OS fanboys. I’m pretty agnostic on that particular subject as I’m dealing simulataneously with Mac, Windows in both server and desktop form, Linux and IOS. Meh, each one sucks in its own particular way and each one has major strengths to make up for it.
As to the AVR environment being best suited to Linux, I beg to differ. Every time the core libraries change, you have to upgrade the whole operating system so you can get the new packages, otherwise dependencies eat you alive. Meant I was stuck in Mega168 land a while when everyone else on Windows was running Mega328s until I could crawl off from under the Econolypse of 2007 and get some equipment upgrades.
As opposed to Windows where you just reload a newer version of WinAVR which tends to be OS Version agnostic. It’s why I gave up on running a separate Linux system, got the hottest quad-core I7 I could afford, installed Windows 7 and run a couple versions of Linux on virtual machines.
I liked your show and it got me, a long times AVR user, to reactivate my dsPIC eval board. Hmm, are pics really that great, if Dave says yes, probably he is right. So I tried it. And you know what? It took me 2 days (!!!) to get the damn thing to work. The drivers for the ICD2 wouldn’t work under Win7 64 bit (how can one even expect that for a design that will retire coming September), then they did, then they actually didn’t really because the ICD2 was from an early batch with Cypress controllers inside, so I had to install Win7 XP Mode to have the toolchain run under a virtual machine. Finally it worked, but until I had figured out which files you had to add where and how to configure the debugger and stuff and that there is a debug and a release mode, the second day was gone. Given, that you base your opinion about AVRs on your first toolchain impression, I believe it is justified to say that PICs can just suck as hard.
In terms of performance, the slow instructions are a pain, but you have more functions in the chip, so all in all- they are the same and the projects determine what you need. The only adavntage I see for going with Microchip is simply availability, the other claims you make could as well be turned around against PICs.
Ha! It’s funny because while trying not to show his fanboyism for Microchip, he shows his fanboyism for microchip.
Wow. I couldn’t finish this one. So much bad info. Yes 50 dollar’s for a programmer isn’t much but there is never reason to waste money. At least for AVR, AVRdude support for serial banging is fine, and very well documented (far better than ARM stuff I have used). Having a debug interface is perhaps nice but most beginners are fine with printf or similar.
I would say the strongest advantage microchip seems to have over Atmel are some of the free stacks it has for supporting parts. For instance software TCP/IP, wireless etc. They are written for PIC and thus pretty much drop in. Atmel doesn’t sell equivalent parts.
The biggest strength of Atmel/AVR is probably community. And this stems from Arduino. That is people who shifted to bare metal design from Arduino.
This is very useful and funny but…
No matter how often the author stressed how much he hates fanboys I got an impression that he is a very clear fanboy of PIC himself. Just hear how he speaks about Atmel and how about PIC.
Now, setting aside the very opinionated and probably unintentional slight fanboyism of PIC in your vlog (there’s no arguing opinions), I really do want to stress that your arguments can go either way.
I’ve been using Atmel pretty much exclusively for small projects because… like you, it’s simply the first thing I used and if I want to start off a project quickly, I want to use a micro of which I have the datasheets engraved in my memory. Simple as that. But in a professional context the choice DOES matter as I’ve found out. I’ll tell you which microcontroller is best: Neither!
In the big component crisis of 2007-2010 (and probably ongoing) both sides of the fence suffered really bad stocks, and basically any design requiring industrial quantities of PIC or AVR were left in the rain. These microcontrollers aren’t scheduled or reserved for professional use! Whenever Atmel or Microchip thinks the economy is going sour, they don’t bother calling up their clients and asking ‘hey, do you by any chance still need these micros in, like, a year?’. They just cut the production line and let the supply dry out.
And all the great documentation and cheap toolchains that Microchip and Atmel produce won’t help daisies if you can’t produce your product. Motorola – with their IMO atrocious 1980′s architecture and worse toolchain (btw, i’m talking about their low-end 6800-based stuff) – have the decency to keep supply up. So if you’re an electronic engineer in the making and you go about applying for jobs with just Atmel or Microchip experience, chances are you’re going to be told that that experience is worth cod and they’re looking for somebody with at least ARM experience – in whichever form they come (if you’ve seen one, you’ve seen them all).
However, having said that there is one rational reason I use AVR, and that is the niche that I live in, electric power processing. They do have some very nice offerings like three-phase two-quadrant encoders combined with USB and some other decent peripherals that you just don’t find in the Microchip camp. But as you pointed out: this is really not a question of AVR versus PIC, it’s application dependent. I’ve just been working on pretty much the same application for a long time…
[...] tu ce ai face pentru cinci euro? [...]
This blog is great. I was introduced to AVRs a few years back and have always use them as I had the tools and didn’t see the need for the others.
But Dave’s blog really opened my eyes to both side of the argument and now I use both PIC and AVR and have implemented PIC’s into a few of my recent boards.
Like Dave said, it is really important to keep and open mind and chose based on the requirements of a specific project. And I found by doing this design and integration was easier as i didn’t need as much external circuitry and software.
I program on both micros, I use wherever micro suits the job.
But I must say, MPLAB it’s really outdated, with an ugly GUI and a lot of quirks (like the tabs requirement on ASM code, nonsense!). I do really appreciate AVRStudio GUI and workflow.
AVR is nicer, but PIC is really competitive.
But, who will use PIC32 or AVR32 when there are better options on the 32bit arena?
Educational and entertaining. It constantly impresses me that Dave can keep talking so lucidly and constantly to a video camera while alone in his garage. I guess it’s because he knows the subject to such an expert level.
Really awesome content, thanks for covering this topic Dave, it’s helped me see things in a new light and to stop worrying about the petty details.
My personal opinion is use whatever the hell you want until it stops doing what you need it to do. If AVR’s do everything you want and you feel comfortable with em…why NOT use it.
What pisses me off is the (AVR especially) fanboys who will use outdated arguments. Microchip DOES have PICs with 1:1 MHz:MIPS even though this pissing contest doesn’t really matter for hobbyists. Microchip DOES have a free C compiler (who cares about code optimizations when most of us don’t even come close to maxing 128/256 KB prog memory)? Microchip has TONS of documentation and application notes in asm AND C.
And who gives a shit what is best with asm? You’re a dinosaur who is wasting time if you try to code up a large program using asm. Coding in a high level human readable language is faster. Period! You might squeeze out .000001% more efficiency but you spent too much time accomplishing it.
This site( Denon avr 1611 ) Are very awesome for the educational program.
I am loving this blog!
I’ve noticed no mention at all in these posts of either the PIC or AVR-based BASIC compilers. I’ve spent some time using PICBASIC PRO from MELABS and really like the ease of use and documentation, plus the support for a wide range of PIC MCUs. I know that there is BASCOM for the AVR and have read some good articles on it in Elektor Mag. Any thoughts on either of these software products? PICBASIC was a good and easy transition for me as a fifteen year RF engineer who hadn’t done really any programming since the early nineties (in those days using DOS Turbo C/C++), being almost all analog. I know most of the embedded world uses C, or the multitude of variants based on C. Just want to open the discussion on BASIC as an easy language to learn. Thoughts, Dave, anyone…
Quote from the video: “… you should be PICking one of them …”.
I find all of this humorous, but in not such a good way.
Dave, you definitely came off as a PIC fanboy.
I’ve been at this stuff for over 20 years, and the only correct information I found here is to choose the right micro for the job. The rest is not very helpful.
None of the professionals I work with use MPLAB or AVR Studio except for flashing the parts and debugging. We don’t use any of the rest of the IDE, don’t create build projects in the IDEs, etc. Doing so locks you deeper into that toolchain and product, exactly what Dave claims you don’t want to do at the beginning of the video. The same is true for CodeWarrior, Green Hills and many others. Try converting one of the IDE projects into a project for a different IDE. It’s painful gruntwork, even if you were not changing compilers and microcontrollers. Of course, if your whole project is in assembler, you’re in for a lot of pain anyway if you switch micro instruction sets. But at least some of the IDEs let you generate a make-based project or if your only development environment is Windows, a Visual Studio compatible project. But no industry-grade software team is going to live without automated builds, automated unit
tests, integration with a slew of revision control systems, etc. which the IDE isn’t going to give you.
The IDE is used minimally by professional software teams.
Dave, what do you consider ‘support’? A good chunk of the automotive world has banned Microchip due to poor support. Working at a tier 1 supplier, I have to have an near impossibly strong argument to use Microchip over just about anything else. The same is mostly true for Atmel, but not due to technical support (which is generally very good in my experience)… Atmel just doesn’t offer very many AECQ parts and the lead time for large quantities of AECQ parts is longer than most. Microchip has been banned in a many automotive shops for a different reason: gnarly bugs that consume large amounts of engineering time and 2 years later still aren’t in the errata no matter how loudly we yell at them and how many millions of parts we’ve bought, and there’s no new mask on the horizon to fix the issue. And to be clear, a significant issue here isn’t necessarily Microchip-specific: it’s the mistake of picking a new part because it has some bleeding-edge feature or peripheral you think you need. Guess what? Life on the bleeding edge usually involves spilling some of your own blood. This is also one of the consequences of letting hardware engineers choose microcontrollers with no input from software engineering. It doesn’t happen in every industry, but it’s somewhat prevalent in automotive in the U.S.
Pick the wrong micro from that big Microchip family, and you might well be in for a world of hurt late in the design cycle. You’re much better off picking from older tried-and-true parts, which shrinks the usable Microchip offerings considerably if you want an industry-grade result. In my experience, ‘bleeding edge’ with Microchip usually means any part that’s been in production for 3 years or less. It hasn’t always been this way with Microchip, but that’s been my experience and the experience of a lot of people in automotive in the last 5 to 10 years. It’s as if they’ve severely cut back on their pre-production testing to the point where the customer is doing most of the testing, on parts Microchip has marked for production.
The ATtiny26 story is pretty laughable. Dave, do you realize the target market of the ATTiny lineup? Almost every place I’ve seen them used in large quantity is to replace dedicated sensors. For example, when you need a couple channels of ADC/DAC, it is often cheaper to drop in an ATTiny24 or the like with a bit of support circuitry versus a dedicated ADC/DAC, and you gain the flexibility of redifining its behavior via software, performing detailed end-of-line tests, loading end-of-line calibrations, etc. In many industries, a part cost difference of $.01 seems to warrant considering design changes (most of us engineers don’t think that way, but the bean counters do). And if you’re an intelligent designer, your board doesn’t prevent you from using high-voltage programming in-circuit with any of the ATtiny micros. The other places where I’ve seen ATtiny in quantity have been simple battery-operated devices.
I’ve used many of the current and not-so-current microcontroller architectures. A few years ago I was on a project with Atmel, Microchip and Freescale micros on the same board. The Atmels were ATtiny, used for ADC and parts of DACs. Reflashable in-circuit, though we used every pin at runtime. Also reflashable over SPI, via a small bootloader I wrote. Ditto for the PIC. Both connected to the much larger Freescale via SPI. The PIC was chosen based on some fancier PWM features desired for controlling a high power AC to DC converter. As it turned out, that PIC, being a relatively new micro, had some critical problems that caused us some large headaches (and some spectacular explosions some of us enjoyed a little too much) that in the end required some somewhat expensive workarounds we had to develop ourselves. To this day, those bugs are not in the errata sheet. Heaven help the person who chooses it for their new design for the same reasons we chose it! This kind of problem isn’t unique to Microchip in my experience. What has been unique to Microchip in my experience is their lack of support when these types of issues arise. The on-site Microchip people are responsive, but support above them is poor compared to Atmel, Freescale, ST, TI, Renasas and others. Maybe things are different in Australia and New Zealand, but that’s the story here for many of us in the U.S. It gets tiring trying to pry information out of a microcontroller vendors’ design engineers, especially when you’re just looking for a workaround. When time-to-market matters, these kinds of problems lead to blacklisting a vendor. Microchip is the only microcontroller vendor I’ve seen blacklisted by multiple companies in my industry.
Today, I think Atmel is a better choice for the casual hobbyist, but that’s largely due to the advent of Arduino, a completely free, unrestricted toolchain that is familiar to a lot of CS graduates (since it’s a GNU toolchain) and is available for many PC operating systems, and on Windows, an AVR Studio based IDE.
Both Microchip and Atmel have good quality low-cost programmers and debuggers, and there are plenty of development kits available for both (including lots of third-party dev boards). Pick one that excites you, and travel forth! In the end you’ll likely wind up using both if it’s your profession, along with a slew of others. You see a lot of Atmel fanboys for the simple reason that Atmel has done a better job targetting the hobbyist in the last 10 years than Microchip. Both work fine as learning platforms, and if you choose wisely, as production platforms in most environments. Both are of little use in automotive, which is sad from the perspective of knowledge transfer from your student/hobbyist to your professional automotive engineer, but it is what it is. And both are better architectures than what many of us have to deal with in many industrial settings (HC08-based architectures extended way beyond their developer-friendly boundary, for example ).
Amazing that noone mentioned the dinosaur that would never die, the immortal, Godlike 8052 ! There are probably dozens of them in my car (even the auto gearbox runs on one of those with 32-bit DSP extensions). You can’t go anywhere without having a 8052 (or 10) in a 5 meter radius. I guess we can be pretty sure that the bugs have been ironed out by now…
Also guess who sold the most microcontrollers last month ? Probably some Chinese company we all never heard of, making obscure uCs that are used in all the chinese crap we all buy (singing gift cards ? toys ? etc). Chinese datasheets only, and they don’t speak to you unless you want 50.000 units.
Microchip gets a bad rep from the PIC16-18, which are really obsolete, and the cohorts of idiots insisting to use them in hobby projects and *programming them only in assembler*. Apart from those fossils, their lineup is not bad.
Microchip also gets a bad rep because frankly, I’ve never seen a Silicon Errata so bad as a Microchip Errata. The other guys all have some bugs, emphasis on SOME. Microchip is on an entirely new level here. I guess their pre-manufacturing validation department must be run by Mr. D. Head (who outsourced the whole thing to a shack in afghanistan).
Seriously, either :
- Microchip is being professional and the other manufacturers hide their bugs well (
- or Microchip just fucks it up repeatedly and sells the silicon anyway
Apart from that :
- AVR : not so bad (but 8 bits, not so much choice of models…)
- Microblaze : argh.
- Cortex-M, STM32 : neat 8-bit killers, cheap, little choice of peripherals though, although NXP hits hard with the new CAN-enabled M0.
- 8052 : when I get reallly old and get a pacemaker, it will probably still run on one of those
I guess the big fat ARM heavy roller is coming, which spells trouble for Atmel and Microchip…
Hello David, really like your blog.
Regarding PIC vs. Atmel – for me (as a complete beginner in µC) i stumbled upon the OpenHardware / Arduino stuff and that was easy enough for me to get a good feeling in µC for a start. Easy enough to get some success early on (even if it’s just a LCD or a blinking LED), but without being forced into a closed ECO-System. After a while i saw, that i could go on “bare metal” if i wanted – but i didn’t need to. So i am neither pro Atmel or pro PIC – i am pro Arduino, because it get’s my stuff done. It’s a bit like AMD vs. Intel or NVidia vs. ATI – it doesn’t matter as long as i can play my games, do my browsing and do my work.
So my 2 cents: AVR is “nicer” for me, as it got picked for the Arduino and i know, that if i would have to “dig deeper” i probably go into the Atmel direction.
so I made an RGB fader on an atmel attiny 14 without ever using a microcontroller in about 5 hours from opening my mail and getting the chip, to installing the software over my slow internet to figuring out the data direction.
I spent 3 months trying to get a pic to blink an led. never fucking got it to work.
The Lord and it can no longer do you want to create a real skill, the head of Design recorded protection body taking bright Heavenly Sword strike directly with Hong Hyun hard war! But is unable to be able to attack directly disgraced the Lord wouldn’t that good. In fact, If the LORD came up on the start, the ability to Hong Hyun will not have this change, under just the Lord’s sparring, Hung Yuen Road slowly but surely expand facilities to Hong Meng sword comprehend deficiency of the defects,
Every year a summary of micro controller sales is done. In 2012 Renesas far outweighed the sales of all other micro controller manufacturers and the auto industry was the largest consumer of micros (unsurprisingly the auto industry use Renasas lots). Atmel moved up in the rankings and now sells more than Microchip.
I am a fan of PCs though and agree with Dave that for a hobbyist starting out the tools for the pic are very good. I particularly like the simulator which I miss dearly when using my other favorite micro the Cypress PSoC.
Leave a reply