EEVblog #63 – Microchip PIC vs Atmel AVRPosted on February 22nd, 2010 120 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)
And check out this way to program AVR chips with the PICkit2
I am working for one big company (T1 sup) in automotive industry and we don’t use Motorola’s uCs at all. We are using uCs from NEC and Renesas. And this choice was made by managers, not by the engineers. …
B.t.w. did you know that the microchip’s C compiler is based on GCC?
Which C compiler? The 8-bit compilers aren’t based on gcc, but the 16- and 32-bit ones are.
Great blog. I agree with all your conclusions.
Yeah, the WinAVR stuff was pretty bad, but I think you’ll find that the installation process is much more streamlined and better documented today than it was a few years back.
I come from an AVR background. I’m using the AVRs because I’ve made the investment in the tools, and haven’t had a need for a PIC that warranted the purchase of a new set of tools.
For a beginner I would recommend Microchip for one simple practival reason – it is so easy to get samples and they come in 1-3 days. Atmel: I am still waiting for those samples I ordered a year ago
WinAVR software is much better now. I actually like it more than I like MPLAB, I didn’t find it complicated at all. I also felt for the fuse trap, I disabled my XT clock in some way and had to connect an external oscillator to bring the chip back to life.
Great video blog – I concur with most of your observations.
In large volume production, there are other secret giants like arm32 which have really little to no share in the hobbyist market. You wouldn’t believe in how many devices an arm32 core is used…
gcc is indeed quite cumbersome at times. But its inherent advantage is that the source code is open and that you can always hunt down and fix bugs if you are proficient enough. While closed source compilers can generate an ‘hello world’ with much fewer pain, you will eventually hit nasty compiler bugs once your microcontroller code becomes large and complicated. Narrowing such errors down and working around them is a sure way to turn hair gray.
I am a pic user, because i can’t find the atmel microcontrollers here, and everyone around me is using pic, so i am currently using pic (maybe sometime i will use some other uC, but right now, the pic line is good for me)
and for coding, i am programming in the BASIC variety of PIC Simulator IDE. it’s pretty efficient, i like that IDE, it’s nice. and the compiler is not bad at all.
they have an AVR version as well, which i didn’t try.
Strange, my experience in Europe is that the PIC fanboyz are usually the ones trying to piss on your feet.
All in all I unfortunately have to state that you aren’t well informed about AVRs and Avr tools. You appear very much like an uninformed PIC fanboy.
I won’t correct all your misconceptions, just the first few:
Regarding AVR in-circuit programming and debugging: http://www.atmel.com/AVRdragon $50 buys you JTAG debugging, JTAG programming, debugWire debugging, PDI programming, ISP programming, high-voltage parallel programming (to rescue botched fuse jobs), high-voltage serial programming (to rescue botched fuse jobs).
Regarding the STK500, it is regarded as one of the best long-term investments among professional AVR software developers. It requires to read the manual and the datasheet. Something that became out of fashion, apparently even among professional engineers.
You are also uninformed on the current status of the AVR GCC compiler or any of the commercial compiler offerings (of which most have free entry-level versions).
In short, you are not qualified to make this comparison, because you are (a) biased, and (b) uninformed.
On second thought, I thing this is the worst propaganda blog posting you did until now, and I regret even trying to correct some of your misconceptions. Because they are by intention, aren’t they?
I’d say you did a clever preemptive strike right at the beginning of the video when labeling AVR users as fanboyz, and then spending the next 20 minutes to drive the “AVR users are clueless fanboyz” message home. Which is a very unprofessional behavior.
There are in fact issues (technical and corporate) regarding Atmel and AVRs which are worth to discuss, but you entirely missed them, focusing on the fanboy insults.
And by the way, one doesn’t hear much of Motorola MCUs these days, because Motorola doesn’t do MCUs any more. They spinned the whole business into Freescale six years ago. Freescale has, among other offerings, nice HC08 MCUs.
I agree with you in most of points and I think they are well founded, but all the fanatic anger you put in your words is rude, useless and doesn’t help to take you seriously.
I say this as someone who uses AVR chips extremely regularly, loves them, and has never even touched a PIC.
Although the AVR Dragon is a very nice piece of kit on paper, especially now that the 32k flash limit has been removed, it has some severe flaws. Primarily, because it’s so cheap, Atmel skipped most (all) of the protection circuitry that is present on the JTAGICE and ISP programmers. That leaves you with, unfortunately, a very fragile programmer that must be handled with great care. It is very susceptible to static electricity damage, and can also be instantly destroyed by plugging it into a USB port that doesn’t have enough current. I have personally had two of them die on me.
Numerous websites have sprung up dealing with how to protect it, and how to deal with problems that arise, such as http://www.aplomb.nl/TechStuff/Dragon/Dragon.html
Furthermore, Dave was talking about being able to render a chip useless while it’s soldered to a PCB by getting the fuse bits wrong. It’s not always practical to use high voltage programming techniques on a chip which is soldered to the final PCB as the 12V reset signal would possibly destroy something, not to mention the number of connections required.
While the STK500 has a lot of limitations, it was really helpful for me. Coming from more of a software background I didn’t want waste all my time trying to design circuits just to test my software. What the in-circuit programmers don’t have are a bunch of headers, leds, RS-232 port, and switches already hooked up. With the STK500 I can quickly learn how to use the I/O ports, interrupt driven serial communications and reading ADCs. I am sure the other tools are better for more serious hardware projects.
Not that you’re a fanboy or anything…
Indeed. He started well with “it doesn’t matter, both are good”.
Then he harped on “the bloody AVR fanboys” a hundred fifty times or so throughout the whole thing, downplaying major advantages (like speed), trying to portray security as a risk, trying to say the ICE is more expensive when it isn’t, willingly(?) ignoring several major advantages (like arduino popularity and ease of use, great linux toolchain, easy 6805-like assembly, etc), saying that the ridiculously simple installer is somehow hard to use and what not. It’s like 99% one-way bashing of AVR-everything throughout (most of it not having much of a basis in reality)
It makes him come across as the biggest PIC fanboy I’ve *EVER* seen.
And that’s coming from someone who barely ever uses AVR’s (I have an old STK200 collecting dust somewhere that might still work). 95% or so of what we use is Freescale (automotive indeed), with some 8051′s (NXP/formerly Philips) in really old products strung along with some basic PICs and the odd P87LPC767 here and there, ARM7 in WinCE devices, etc.
Don’t get me wrong, I have nothing bad to say about the PIC. The PIC18F series seem very nice (not that I’ve played with them), especially for being able to do pin reassignment. I’m just saying that Dave comes across EXACTLY like the type of fanboy he accuses the AVR users to be (aka dickhead, to use his own words)
It’s really all good, there’s lots of great MCU series each with their own strengths a large selection of devices… But here all you did is bash AVR guys endlessly about nothing.
Great blog, but I agree, it is an infinite discussion!
I mostly use PIC controllers with mikroC compiler and tools myself (and feel great about the tools AND the compiler, by the way). I have also tried programming NXP ARM controllers and Zilog controllers during some university projects and found these uCs to be great and to have great development enviroments and kits too. The main difficulty in switching between microcontrollers is that everything, every feature seems to be same, but takes some completely different code to initialize, and requires a lot of effort and datasheet studying, which may seem problematic for a beginner trying to pick a micro. I remember, that I started out with PICs simply because they were the only ones available for sale here in Denmark, as the most of the projects I read about were built using Atmel controllers.
Why do people use homebrew programmers? Because they are cheaper! I’m living in central Europe and I’m studying electronics. I’ve a scholarship for good grades (the third highest possible actually) which is ca. $150. So why should I buy a programmer (lets say an AVRISP mkII) for $60, if I can make a programmer (or even a clone!) for $5, which does the same job?
And still, I would close each and every university which still teaches ONLY 8051 (even if it is an AT89S51 with ISP capability).
One reason I’m partial towards AVR (which may be of particular interest to hobbyists) is that the development tools are relatively easy to install and get working in Mac OS X, since a lot of the tools (avr-gcc, avrdude, etc) are just Linux packages. If I just want to throw something simple together, I can create an xcode project and have my computer talking to the uC in a few minutes.
AVR tools package for OS X: http://www.obdev.at/products/crosspack/index.html
For larger projects, obviously, I’ll spend more time considering which uC would be best for the application, and in those cases it’s usually worth moving to Windows for a while so you can use a manufacturer’s official tool chain (Freescale for the S12 for example, or Xilinx if you need an FPGA).
I’m going to have to agree with Oren. I was (at one time) a rather rabid PIC guy, but I found that it was expensive or difficult to do PIC C programming on a Linux platform.
Tools I use: AVR-GCC, AVRDUDE, and a USBtinyISP programmer from LadyAda.net.
Since I’m a dyed-the-wool gcc / make user, using avr-gcc was a no-brainer. I have “make” targets that program the chip.
On Ubuntu, I simply do:
$ sudo apt-get install gcc-avr avr-libc binutils-avr avrdude
I’m up and running.
i was waiting to hear your point of view about this since i watch “eevblog”
I agree Dave may not be completely up to date on AVR tools, however he did make a point of mentioning that fact and encouraged further investigation on the viewers part. IMHO the main point of the blog was well done. Have a look at both and pick what appeals to you, It’s not the end of the world either way for a hobbyist and it’s good to be diverse as an EE.
That being said I’m a hobbyist who started a little over a year ago and uses AVR. I chose AVR as from what I could tell it was gaining momentum in the hobbyist community. I found a lot of recent online projects, tutorials ect. that seemed relevant to >>me<<. It also didn't hurt that my first microcontroller experience was an Arduino which uses an AVR.
I wish I saw that advice on home programmers first.
I must have spent $40 on programmers and cables, none of which wound up working right. And, when I built one that did, it wouldn’t work with my new computer! Horrible.
“So come on fanboys point out all the errors, etc. etc. I don’t care, you’re a dickhead!”
I laughed hard, this is one thing I love about this blog; your candor in pointing out dickheads!
Pretty much agree on all points, I’ve used AVR at uni on the STK500 and other processors (MSP430, dsPIC, etc) and thought your analysis was pretty spot on.
I’ve been using PICs for about 15 years and have a fair amount of experience with the mid-range devices. I totally agree with Dave’s point about speed. The PICs are fast enough for my needs. The important thing to me is overall ease of use or development time. So I would hope that more people comment on this aspect because I’ve had good and bad experiences with Microchip. A “read-modify-write” problem can set you back weeks with PICs. Are the Atmels any better in this respect? In terms of general funkiness that you have to be careful of which is better?
I recently worked with my first baseline PIC, PIC12F510, and am disappointed with it in general. I was looking for a PIC like the mid-range PIC12F675, only without the 10-bit A/D and 2 timers. The 12F510 seemed like just the thing, but holy cow! That chip is stripped! There’s no interrupt capability, the sleep functions are all boogered-up. So much functionality and flexibility stripped out. Why do that? It’s chip funkiness and Microchip marketing BS that make me want to look elsewhere.
I know the problem you are talking about. In PICs changing an individual bit on an IO port can result in unexpected behaviour if some of the pins are being forced high or low. The AVRs use separate registers for reading and writing, so aren’t affected by this problem.
Say you didn’t plant that question did you:).
PIC12F629 is on pair with PIC12F675 but without ADC, as you wanted. I’m using both (PIC12F675 as solar/windmill controller and PIC12F629 as stepper controller).
I’m using Microchip micro:
– 18F2525, 18F2550/4550(in Arduino form factor and style )
– Chipkit Max32 board with PIC32(in Arduino form factor and style )
I’m using ATMEL micro:
– ATmega644P (first, bricked an ATmega32, me being dumb), and I’m planing to use ATtiny45/85, ATtiny44/84, and an USB part, AT90USB1287(because is still at 5V and better than 18F4550). I don’t have yet an Arduino but I did a Sanguino (having in mind a CNC Router and/or a RepRap).
Also I plan to learn and use an 8051 compatible, AT89S8253, using free Pascal language(turbo51).
I don’t care about Microchip or ATMEL, I care about me. I learned in time to appreciate Dave’s video blogs. Some times are educational, some times are fun, and some times are both.
ha ha ha
what have you done Dave
you make Fan boys angry, i smell war blood, and revenge
i don’t gonna say im pro. usually i use some kits what are already done.
like bee or aduino (or whatever they call it)
i also need to have board connected to the computer, to control stuff from the computer, etc..
i dont pay attention to brand, name, history. whatever. i just use this what have best specs for this what i need to do. (or im just buying first what do this what i need, without researching any further)
thing is i never used pic or that other device. and now is the important part.
after this video, i would go for PIC first, because as Dave said, can support more processors, and its easier in use.
but if i would have processor what need the AVR i would buy AVR.
simple as that.
and i like to watch this blog because Dave has thousands years of experience !!!
what is BLOODY CLEAR.
and if its working for him, it should work for me as well.
all his opinions are his opinions, they might be even not right. (doesn’t mean this what he is doing is not working)
and i really, really like that.
i also dont understand why people write comments with links and corrections, etc. to this what dave said.
who cares ??
go and do your own blog is you have something to say.
im pretty sure you much to say. other vise you would have a blog.
IT IS HIS OPINION.
please leave it alone. i dont want to watch Dave blog what is politically correct and with extreme care Dave trying to say something and dont hurt anybody’s feelings.
dont like it? go and do your own blog
damn, i got nervous lol, am i becoming a fanboy of Dave’s blog ?
I am a microchip fan boy through and through, but have you seen that Atmel microcontroller with a zigbee module onboard, common microchip keep up!
Nice little comparison there.
Most definitely have to agree with the points you’ve made regarding the chips, excepting the C environment, seeing as I don’t use C much with micros (I’m an ASM programmer, not because of hatred of C or anything, just because I’m better at using ASM on micros).
Atmel chips and I share a mutual hatred of each other, mainly because of the amount of screwing around with all of the different programming stuff which was a pain in the ass when I was first getting started (didn’t have the option of using another chip). However with that said, after using at uni for the past year, I use them almost exclusively now, mainly because I’m familiar with them now (still don’t like them much though).
I’d probably go for PICs if I was doing stuff that didn’t require heaps of grunt. Otherwise I’d go for an Atmel (unless it required something more in the region of a 16/32 bit chip).
As far as I’m concerned, they are just tools; means to an end, in some cases one is more appropriate than the other, but at the end of the day they are just bits of silicon (something that some fanboys haven’t gotten into their heads yet).
I use PIC micro’s mainly because I’m familiar with them and sticking to one MCU cuts the cost buying multiple development tools.
I also use PIC’s because
1/ A uk electronics magazine (Everyday Practical Electronics) publishes designs that use them. Great for a beginner like me.
2/ I am able to use an open source BASIC compiler (Great Cow Basic) for quick lashups.
3/ I have a great book by Di Jasio that teaches the use of PIC24 using the Explorer 16 board,ICD2 and MPLAB/PIC C compiler
4/ There is a an entry point for learning more about DSP by using the dsPIC.
I started learning about MCU’s on TI’s TMS370 at college. We had to do everything in assembly language. It was a pain, but it really gets you close to the metal. But for practical use there’s no substitute for C.
A good technician uses whatever tool (software or silicon) gets the job done.
OK I am a Fan of Atmel AVR’s (not a “FanBoy”) but this is only due to the fact I had to use AVR for a company I worked for (I did not complain as I got to learn the AVR while being paid (always good)) before that I used the 8051, 1802 and the z80.
I have bought a lot of tools for the AVR (ISPMkII, STK500, 501,502, JtagICE, JtagICEMkII and the ICE PRO), I also own Codevision (but currently use AVRGCC).
If I moved over to the Pic, I would have to buy more tools and software (doing things like TXing DMX512 while communicating with the host PC using USB takes a fair few mips and you need all the optimisation you can get
But above all, if a project is cost sensitive (eg large production run) then I would choose a uC with the features I need, not only due to the tools on hand. But this does not happen often, most of my customers are one off’s (or a production run under 100)
In fact most of my customers come to me because I use AVR lol (to quote Dave “Go figure”)
Firstly, I’ve been using Atmel’s AVR microcontrollers for about half a year now. It’s great so far.
However, I’ve heard so many great things about PIC processors and would like to get started on playing around with them. However, there seems to be one major problem — I’m a Linux user (i.e. I don’t have Windows installed on my machine).
My first impression is that it seems like PIC development tools for Linux are terrible. It seems that Microchip has little or very poor support for Linux.
For a linux user (and programmer), Atmel’s gcc toolchain fits very well with the Linux development style. Their compiler (because it’s based on gcc) is 100% free with no restriction to their complete AVR family (unlike PIC).
Any advise on getting started with PIC for a poor Linux user would be much appreciated.
I second the complaints about PIC + Linux. I don’t use Windows either, and haven’t found Microchip-capable software that claims to work on Linux. If I’m at Atmel fanboy at all (which I doubt, as I’ve hardly done anything with either AVR or PIC), it’s because I’m an open source fanboy, hate Microsoft, and can only use AVRs because no PIC software supports my computers.
As an aside, I had very few problems getting avrdude + avr-gcc working nicely on my box. As I said, I’ve done relatively little with it, so perhaps I’ve just been lucky so far.
Have you Linux folk tried running the PIC tools under WINE? I haven’t tried it myself, but it could be worth a shot.
Dave you did it now,
32 comments in the first few hours already.
You might as well have worn a gestapo uniform to a barmitzvah!
At my work, we have not used very much either one. We are among one of the largest design houses here in Finland and quite a few large companies outsource their design work, which is not their core competence, to us. So I get a pretty good view what
Janne, I think you work among uprocessors rather than ucontrollers like AVR or PIC that are nowadays much more like system on a chip with ALU+ timers/counters+ adc/dacs+ coms port and so on
ARM and FPGAs are more similar to stand alone math cores than ucontrollers with a lot of stuff around them on a chip.
I personally prefer PICs and Motorolas because I know them better and learned with them.
But for hobbyists I think Atmel has the advantage this days, because of the dynamics the arduino-projects generate. There are some really nice and interesting projects, like the RepRap for example.
Just one very minor correction to the video blog:
At exactly 18:00 minutes, when discussing the common misconception that you can’t use the PIC 16-series with a C Compiler, you accidentally gave the impression that the problem was with the 16-bit Micros. Of course, you meant to say 16-series, no doubt about that. So I’m not saying you’re wrong, just pointing out the verbal typo in case it confuses beginners.
With regard to AVR vs PIC, I’ve never actually used an AVR so I’m in no position to comment about which is better from a technical point of view. However, when I was starting out I found that there were far more hobbyist projects out there for the PIC that you could sink your teeth into, and the support was far more widespread. These days I think AVR have caught up a bit, especially with their AVR Freaks forum, but I still don’t think you can get the same widespread support for AVR as you can for PICs. I think PICs are still more common amongst hobbyists, and that’s something to consider.
I’ve only experimented with the PIC 16-series to date, and I’ve dabbled very briefly with the PIC 18-series, but I’ve just got myself the Explorer 16 development board so I can start playing around with the 16-bit devices. I’ve ordered some cool daughter boards for it too, that plug in via a neat “PIC-Tail” expansion connector. Specifically, I’ve ordered a VGA board (full colour LCD with touchscreen) and an SD card board. Can’t wait for those to come – I’m expecting them tomorrow!
So yeah, good blog. I can see that you’ve already upset some AVR fans because you showed a minor (and weak) preference for the PIC devices. Oh well. If it’d been the other way around, you’d have attracted the wrath of the PIC fanboys instead. Even though you did clearly state, more than once, that it doesn’t really matter which one the hobbyist chooses, and from a professional point of view it only matters in as much as you need to choose the right device for your application, which will be different between different projects.
If people are still upset after that then… what can you do eh?
Now that you have done the blog on which uc to use how about a real world application blog on using a pic or avr with lots detail on setup, progamming, debugging and tuning?
Good idea Todd. Because there are lots of traps for beginners! Like, for example, forgetting to set the ANSEL register properly on PIC devices (which can result in unpredictable behaviour of the IO ports) and stuff like that.
I got back into hobbyist electronics again recently thanks to the fantastic little Arduino.
It’s pretty cheap, has a fantastic community, and is easy to program with just a USB cable. I’ve moved on to stand-alone micro projects using Atmels now, mostly because I’m used to them, and (as a Open Source programmer) I love gcc and libc-avr. The Arduino IDE is extremely easy to use for ‘non-penguins’.
Your rant against fan-boys was funny, Dave, but you actually started coming across as one yourself in the middle there…
It’s actually good to rant against fanboys, maybe it will make them think a bit about it
I have been playing with AVRs for many years but that’s just how I started, I liked the architecture so I stayed with it, fine for hobby as you said.
Some time ago I made myself goal of exploring and trying (at least some basic stuff) as many different micros and architectures as possible and I enjoy it. Now I know there are indeed many choices, suited for different needs. From time to time I check also some of those PICs. Microchip has some nice features here and there: good prices, nearly everthing in THT/DIP, broad range of features, the recent XLP family looks nice and so on. I like their support chips and peripherals, they work very well even with AVRs.
What I tried so far? From AVRs back to recent Atmel/NXP 8051 derivates, back to good old Tesla 8048 and Intel 8042 for fun NXP ST7, Atmel SAM7 ARM, even the Atmel AP7000 which runs Linux on nice devboard. Also Cypress PSoC is very interesting family, now being enhanced with 8051 and ARM cores instead of the old proprietary Cypress M8C (which I played with), we’ll see how it will go. The latest experiment being NXP Cortex-M0 on LPCxpress board which just arrived today. I also plan to try PICs more than blinker, I’d like to get something else than the old 8b 35-instruction series which isn’t much fun for me due to some architecture limitations.
I also have more chips from Maxim, Freescale, and TI but currently no way to program them
And guess what? There’s tons more! More that I can ever handle. So indeed keep an open mind, search and try, see what works for you and your projects and don’t hate the others
EEVBLOG said “Also, I can
I’ve never used an AVR, but my first microcontroller programming was done on a PIC 17C756A about 10 years ago, before the PIC 17s got abandoned.
I suffered for a year with the (then) horribly buggy Microchip C17 compiler, and then bit the bullet and ported to Hi-Tech C. The big problem was the peripheral library routines–I’d made the mistake of relying on them rather than figuring out how the silly peripherals really worked and coding little wrapper routines of my own.
However, once I got over that, I was much, much happier. The Hi-Tech compilers are really good. My current project is using the Lite version, but once I get a bit of funding, I’ll definitely spend the $1k for the Pro version. It just makes life a lot easier.
Great episode–don’t try one like that on the road!
Many moons ago a project I was designing needed specific peripherals on the controller.
At the time, the AVRs had that capability at a reasonable price.
Since then I have invested time and effort with the AVR platform – from the days when it was ‘cool’ and only played in small pubs, through to now when it does stadium shows with Arduino
- or, I used it when there was not so much buzz – or even info out there. I am glad to see it now has some footing in the hobby market.
Now, I am in no way a hardcore code guy. I wussed out way back and do most of my stuff in MCS Electronics BASCOM. I still inline ASM where needed though – but honestly, why go to all the pain of general code flow in ASM if you don’t have to! My code and controller is a means to an end – it is there to push about other electronics to do things.
C and me just never got on. I blame uni where I was taught to code in Pascal (TP 7!). For that reason the C syntax and I always clash. I could go with it if I had to, but I have other tools that let me get my job done with what I know now.
And I still use TP7 now and then for quick tool development (recently needed: converting 16 bit audio files into 12 bit data statements for including into program code).
I always wondered if I was missing anything by never really playing with PICs. To my knowledge, not really – each manufacturer seems to try leapfrogging the other so the same capabilities/peripherals seems to come by in cycles anyway.
Most of all, it is a hobby for me, so why not use what I am comfortable with, and am still having fun with!
Why not do this blog 3 weeks ago.
I just had the third party programmer experience.
Problems programming a 16f819 while the 16f648 worked fine for months.
So i ordered the pickit2 and it worked first time and still is.
I can only say you are right Dave. Sorry for the people selling they’re own pic programmer but the price and features of the pickit2 puts you out of business.
PIC’s are excellent in getting a simple to
moderate job done but the low end 10 to 16 PIC’s are a bit limited if you want to use it for some highly structured program with many function calls and re-entry functions.
My first micro was the classic PIC16F84. It was easy to get one from DSE at the time(for some crazy retail price) and I built the cheapest PIC programmer I could find schematics and software for. It was lots lots of fun learning about micros. (Flashing LEDS and driving LCD screens i.e. the usual geeky stuff). Later I needed more pins and DSE didn’t have any PICs that fit the bill. They did have some 40 pin AVR devices (AT90S8535) on clearance. So home I went home and built the cheapest AVR programmer I could find schematics and software for.
I had originally been trained in X86 ASM and found the register/instruction set arrangement in the AVR to be more familiar so I stuck with AVR’s from that point on.
Flash forward a few years and I started my first embedded software/firmware job. Low and behold the first task was to make some changes to some PIC assembly in an unfinished project (basically the PIC had to translate between two serial protocols). The task was fairly simple and didn’t take long to complete. At that point everything was working fine.
The problems began when the prototypes were complete and placed in the test chamber. Once they hit -10C some of the PICs would randomly erase themselves. If I remember correctly the issue turned out to be a bad batch of IC’s but it took quite a while to properly identify the issue. The issue (along with a previous unreliable reset problem that was before my time) left such a bad taste that PICs were added to the company “shit list” of products to be avoided. I’m not suggesting this is a typical scenario but it’s not something you forget.
Since then, most of my work has been in C on MSP430′s and various DSP and ARM platforms. The quality of the different IDE’s/tools varies but if you don’t crash them at least once a week you probably aren’t trying hard enough.
The bottom line is that I’ll continue to use AVR’s for hobby work until there is some compelling reason to change (such as needing more than 8 bits). I find the free tools to be better than commercial options on some other platforms. In the end you use what you know will get the job done. For most people it’s probably going to be whichever one they started with.
I am an EE and the thing is, as what he has said, USE WHAT WORKS for your project. Sometimes PIC is better than Atmel and Atmel is better than PIC. What matters is that when you stay open you’ll end up with the better part, (be it atmel or pic), and have a better design for whatever project you have.
As for the fanboys…c’mon grow up!
Love how the arguments always seem to stay with PIC, AVR and Motorola… when for some situations a dirt cheap CPLD actually would work better for the project (when you need parallel logic). When I was still in college I worked an internship that used PIC18s for control panels, Motorolas for system board controls, FPGAs for high speed switching, and CPLDs for peripheral management and programming of the FPGAs on boot up…..
My current project has requirements for 7-8″ LCD touch screen which makes me look at ARM, specifically the TI OMAP35XX series (and possibly the OMAP4 later on). Now I am not exactly a hobbyist.. but I do some projects on side (already thought of 7″ LCD Android with 4G support, in 2 DIN box, I might start after this current project). I just figured this all might prove that you work based on requirements, not based on companies or architectures…
I have been following EEV Blog for a while and I love it. My company exclusively uses AVR on all of our products, which is what I came into when I started. However in our newest product I am considering using a PIC because it fits my budget/feature ratio. As Dave and many other professional designers have said, you pick your MCU according to your objective/cost not to what makes you feel warm as fuzzy inside.
Thank you Dave, for the entertainment on my long drive into work in the mornings.
but… does your company allow you the time to learn another micro core?
Smart companies will. Joe
I guess it takes one Fan boy to recognize another. I loved the entertaining dribble, but wish you would learn the difference between the manufacturer and their chips families. Comparing PIC to Atmel is just plan stupid. You meant to say AVR and PIC or Microchip and Atmel.
Anyway I guess it is time I bought a PicKit 3 and then work out which the zillion PIC I need to use. that is when Atmel are good, limited selection means you get used to knowing what you can do.
AVR, PIC , Motorola, Zilog all suck.
The problem ? Single vendor cores !
I prefer cores that are used by more than one vendor, like Arm7, Arm9 , Cortex, 8051 , MIPS and the likes. Multiple reasons: if one manufacturer does not have the peripherals that you need there is another that does. Competition is good and it means i don’t have to learn a new core, just peripherals.
Besides that : pic is an archaic bass-ackwards architecture and difficult to work with (all the fussing with the fusebits , read-mod-writes that don’t work as you would expect and a crazy paging mechanism.) AVr : i don;t know , never used it and never will (single vendor core is a no-no)
CPU’s i use : Silicon labs 8051F120, ST Cortex M3 family, Arm7 based STR7xx family
I’ve been using PIC the last years, at first I coded in ASM and one of the biggest beginner trap is the memory bank selection bits, I spent a lot of time debugging because of those bits. It’s not a problem anymore.
I don’t know about bank selection bits in AVR, cause I’ve only used them once in Arduino. Anybody knows about them?
I’m not aware of any AVR device that uses banking. I believe it’s only the 8 bit PIC12 and PIC16 series devices that use it (and only when there’s more than 256 bytes of RAM). If you’re using C you can usually ignore it but IMO it is an extra pain to deal with in asm. I understand that some of these issues mean that it is more difficult to produce efficient C (or any HLL) compilers but as Dave mentioned Hi-Tech C is pretty good.
Sad, I looked forward that you may have pointed out the technical differences between the PICs and AVRs. They have certainly any advantages and disadvantages depending on the application you want to use them for.
As you I am using PICs since a long time (15 years or so). AVRs I use only sometimes since 3 years or so.
You may consider picking up this issue again and do it like you do all the other comparsations.
Just point out what you mean is good and what is no so good on both of the approaches from Microchip and Atmel.
Hmmm, I might consider doing a blog myself, but can not really tell much about AVRs, unfortunately.
According the 8 Bit entry lines the battle is Arduino vs Assembler, though choice.
Well – as already mentioned AVRs have a pretty neat toolchain for linux users. I myself ordered some PIC32 samples from microchip and tried to get a pic32 toolchain up and running.
First of all there is the question of the C compiler – microchip has released their sources and with a little bit of hacking you can compile your own pic binaries under linux. Now there is the quesion of how to flash a pic32 – and it simply is a pain in the ass. You could use pk2cmd ans pickit 2 – but it will not support future microcontrollers, so this is a no-go. So I tried to use openocd and a xilinx parallel programming adapter. And it turns out: It works. Partially. I can erase the flash and program single words – but the hex file generated by the microchip linker script has configured other flash banks than the openocd driver accepts. And that’s where I am hangig: As long as microchip doesn’t have support for a free operating system it simply is not even remotely comparable to AVR.
(You could now mention, that I should use Windows… but I’m a linux fanboy and have come to the conclusion that I am just too stupid to use a Windows System. )
As I understand it, pickit 3 does support PIC32. What’s the problem with using that?
I have been looking at PIC32 as an upgrade from the SAM7 (Atmel’s ARM7TDMI-series). But currently I am a bit unsure as the “free” C-compiler seem to cost almost $1000 if you don’t want the evaluation version. I’ve ha trouble actually finding information on what they have removed from the free-version.
pikcit 3 does support them – but afaik there is no linux tool for it.
The “free” c compiler: http://www.microchipopen.com/wiki/index.php?title=Help:Building_ccompiler4pic32_under_Linux . There is a sourceforge entry for it: http://sourceforge.net/projects/microchipopen/ and the licenses look good.
here is my ‘just started’ track and story. i’m a complete new in MCU, but have been programming computer software for a long time (basic,c++,pascal, very little in intel assembly). recently i’ve started a project (big and will take a long time i think) that require MCU(s) to interact with PC (Personal Computer! not Program Counter!) to control many motors in PWM + sensoring (robotics project). i’ve been thinking of the project many years ago, but buried since i dont have strong electronic background. it emerged back when i found arduino mega in ebay. then months and months of research until now. and guess what? in the middle, i stumbled and ended up here in this site!
DAVE has saved me alot in my ass from the beginning. from his advice, now i got PICKit2 (not 3! or other 3rd party), cheap RIGOL, and some PIC MCUs just right next to my atmel arduino to be fiddled and learnt. i’m about to buy the AVR ISP programmer but later cancelled after research and found out i can program the arduino through its bootlader via WInAVRStudio->Hex->Avrdude->stk500->USB which is all i need. Arduino C IDE is too slow for my need. and i just noticed and went to a link above this video indicating ATMEL can be programmed with PICKit2! if thats workable for my 1280, thats a heaven! DAVE has saved me again! now i can program both PIC and ATMEL with just a PICKit2 aka 3ch 100KHz LA!
so i think my race in learning both PIC and ATMEL are about at the same pace. here is my conclusion:
installing and programming in both WinAVRStudio and MPLAB/PICKit2 are equally easy just as downloading to MCU (of course with some fiddling and reading manual). but the problem is… after checking my software/logic/algorithm/simulate and downloading… my program didnt work in the 1st, 2nd, 3rd and many many recompilation/ correction later. and guess it happen to which MCU? BOTH! PIC and ATMEL! they both sucks and pain in the ASS while debugging! i dont have hardware debugger for both (expensive), i have to sort some other technique to debug like light up LEDs etc.
basically, they both same and both got errata in the back of their datasheet. so guess nobody’s perfect. but i’m prone to ATMEL due to the fact the MCU (ATMega1280) is more suitable for my need/project, ie 100 pins = more I/O’s, large number of Analog and PWM ports compared to PIC at my hand right now and in ebay. its difficult to find PIC MCU that can beat ATMega1280 (8 bit MCU) in term of I/O’s features. but its truly a shamed that ATMEL provide nothing or very little on project examples, not like PIC (with exception to Arduino IDE, i’m talking about AVRStudio). i have to find project examples in the net and other sources.
even that, mega ports is not enough for me, i need around 64+ PWM and ANALOG! maybe i’ll be buying another 2 or 3 arduino mega in the future. for now, i tried to simulate PWM signal in another (unused) digital IO’s. i tried this in main program loop. Arduino C IDE failed at simulating PWM at desired freq. guess what?! the PWM signal only run at 0.5Hz cycle! how pathetic! it goes to MIPS issue, atmel really have an advantage at this MIPS=clock compared to PIC MIPS=clock/4, considering at current price range and availability of MCU in the market that accessible to me. but hey! they both cheap! not like Intel Quad Core!
for now, i’m working with AVRStudio Assembler programing ATMega1280. more assembly chunk to develop, not because i’m an assembly programmer dickhead!, but really, i need it in assembly coz my MCU are going to talk to USB, read analog, write/simulate PWM at full speed at all time for at least at 100Hz cycle! thats the (my) spec requirement. so guess i will have many times headache with this atmega asm for this several days/weeks.
but that is not it, later i will hack/reprogram my existing servo controller board which used pic30f2012, coz the board manufacturer who programmed it really suck, they are dickhead! the PIC is not working as desired to control my servos.
so i guess sooner or later, i will dance, rock and head banging with this both PIC and ATMEL. as DAVE said, which MCU BRAND is not really a matter. what really matters is our project is up and running ASAP IMHO. i’ll sure to keep my option opened to both PIC and ATMEL. thanx DAVE for the advice and this is the video that i’m waiting for since day 1 i entered this site, and i need more actually on which PIC MCU features that can beat the 100 pins, 16MIPS ATMega1280 at the price range. and sorry for my long story. this is what happen when i take a break after a series of assembly programming (head banging!) and found out the video that i’m really waiting for.
You could try http://oshonsoft.com/ , it does PIC with USB and AVR, you can load any HEX in to the simulator or write code in it’s own BASIC or Microchip Assembly.
I have used PICSIM for nearly five years and had great sucess with my projects.
thanx for the advice i went, downloaded and tried the eval. sadly it didnt support my mcu. and the interface, i think the built in AVR Studio Simulator (Freely distributed) is much better which i can step into line by line, modify registers, data memory etc. This feature i think AVR wins over MPLAB which dont have that level of interactivity during “simulated debugging”.
If you really need massive amounts of PWM outputs, then I suggest that you consider CPLD/FPGA approach. I think that makes much more sense than trying to squeeze that last MIP from tiny
thanx for the advice. if it has massive PWMs, ADCs and more processing power, then it will be great! but that CPLD/FPGA thing, by the name itself, already make me scary. i havent research yet, but as i said, i’m a total new and baby born at this uC. i’ll take my time on it, when i have some.
thanx to arduino creator that have made me this far. with it, i dont have to study how to connect USB chip to uC and then talk to PC using the dready protocol. without it, maybe right now i’m only still studying how capacitor and transistor works.
believe it or not, i still dont understand whats pull up or pull down resistor is all about. but yet, i already made my PC controlling servos. Arduino? WONDERFUL!
solder that tiny soic? arghhh gimme a break, somemore with TQFP, PDIP or whatever. CBGA is rulled out, i’m not going to touch that, only crazy ppl do it by hand! i screwed many of them, mostly on PC board. sorry, but thats just me, non EE gigs.
but i believe electronic discipline is really great and have made a significant advancement. they have made their devices as a total working blackbox for us non EE. we just program the input, and walla! there goes the output!
“Then you can use the
Yes, I have heard about overclockers indeed.
And I know also that on a C64, the best demo programmers were those who could squeeze most out of those 64 clock cycles per horizontal scan line (on every 8. line, there were less clock cycles available). That meant that you counted just about every clock cycle of your carefully handcrafted assembly code required to get the timing right.
I mean that if majority of the CPU time goes for just simple time-critical bit-banging, then the CPLD/FPGA is a better choice for those (like creating massive amounts of PWM outputs). Just add a timebase counter, compare registers, and comparator for each output. Nice and simple. You’ll just need the chip which has enough IO’s.
wow. thanx alot fren. you seem have many experience. i’ll look into it.
Dave this was your worst post/blog ever!
Personal opinion is ok,
but blogging about wrong things,
regardless which side: pic or avr,
is not the style I’m used to hear from you.
the whole video sounds like
you were searching a way to provoce
This is not “engeneering” style,
perhaps you should have called it “offtopic rant”. Perhaps then I wouldn’t be that dissapointed.
(who uses and likes both)
I feel the same about this blog.
Btw. the stk500 has an isp programmer on-board.
Maybe Dave did not understand the tool set.
I am just successfully working on an webserver using a dsPic33FJ128GP.
The 16 and 32 Bit lines from Microchip are very good, but the 8bit line is horrible. The success of the 8bit Avr has a reason,…
Rubi, im a beginner, and if a professional enginneer cant pick up and understand the toolkit quickly and simply, whats the hope that i will within a week or two, likely im going to get the shits and give up or move on or do something else like buy a pickit or an ardunio.
That’s not the point!
I can say, that I am a professional,
I’m making my money with electronics stuff.
Your answer is the best proof for my point:
Beginners get a negative feeling for AVR
with Dave’s post.
My point is not “ohh no, AVR is much better!1111″.
My point is:
damned there are reasons for pic, there are reasons for avr, and although Dave said
the same thing, the content of the video
doesn’t reflect this.
You reaction is the best proof I could get.
If you’ll choose PIC: gratz, best choise!
If you’ll chosse AVR: gratz, best choise!
As a beginner, the best choice is the Arduino, imho. There are many solutions for common problems available, called libraries and you do not have to mess around with registers or interrupts.
Just wondering why everybody keeps talking about pics and avrs and nobody says anything about ARM and 8051/2. I mean, why don
Recently Michochip brougth ZeroG wireless.
I have one of their cool boards, I was going to continue working with their wi-fi boards but suddenly this merge…, and specially when I was waiting for the next silicon revision.
I hope microchip has good plans for this technology, what do you think guys ?
I don’t agree with you about books for PIC and AVR. There’s a host of stuff for PIC, but the AVR books (esp for the newbie) are pretty minimal. In several cases, they are just downright woeful. And, gee, unbelievably expensive.
Yes, those fuse bits in the AVR will give you endless trouble. And the instruction set of both PICs and AVR (if you are learning to write assembler code) will drive you swiftly to drink. Or C. Not sure which is worse.
I certainly don’t agree with your comments on speed. There are a number of designs that just straight out require plain old processing speed. The AVR wins hands down. No, that doesn’t mean I’d only use AVR. But I’d probably grab one first if I needed speed.
As for (sort-of) suggesting beginners take a look at 16 bit and 32 bit processors. That’s a very costly way to learn. Strongly disagree. Invariably much harder to learn with those.
If you are just learning, then like several universities (with limited budgets), there’s nothing wrong with teaching 8051. At least the instruction set is logical, there are lots of jobs out there looking for 8051 experience, and there are very few odd things to get in the way of logical programming (unlike not being able to use registers below magical #16 in the AVR with certain instructions, or no bit set/clear AVR instructions, or the oddest I/O commands in the world, and no multiply/divide in low end AVRs, or strange pointer offsets or….And don’t get me started on the really weird PIC instruction set!) In any event, what you learn with 8051 or TI’s 430 or the Cypress chips etc is all easily transferable.
Yes, I know. Use C and avoid these code problems. Except C is not the solution for everything, as you know.
My recommendations for beginners:
1. Check what chips you can buy cheaply and easily, and try these first
2. Check if you can get help for the stuff you are planning to buy/use (Friends, books, vendor advice, fellow engineers) because you’ll need it
3. Build a programmer if you cannot afford those $60 vendor things. (They work well, but you need good advice to select the right design to build)
4. Start small and take small steps. Always a good plan when you’re in the dark and don’t know your way.
great advice and commentary, thanx. esp 32bit mcu. i’m yet into it, so it seem that i have to master 8 bit 1st b4 moving to 16 or 32 bit mcu.
for mcu speed. i think thats a personal flavor, some need it, some dont. for DAVE comment, we cannot say he is wrong, because he is proffesional, he already mastered the faster 32 bit mcu and can easily switch to that, he needs to complete his project fast, hence program in C, he doesnt care SRAM or flash size, coz he got abundant of choice at hand. and he builds multi million dollar equipment. we and certainly i, are out of the league. but great thing about him is, he do cares about beginners.
what you see and hear in the video is a comment from proffesional point of view with years of experience.
when i used to program during pentium 1 age, most of the time i concerned about code efficiency so it can run fast. tweak and optimization waste some of the time, mostly. but now, i got GHz machine, and code in worst manner ever (to increase readability and reduce development time), but still, the code run in hundrenth fraction of time of a blink of eyes. who cares?
6502 is the only way to fly pal!
Just kidding… great rant dude.
Agree that both have some interresting features and should be considered when designing a system. I’m using pics more often through.
Should say about the point that AVRs are faster.
Actually I’ve used AVRs only once in serious project an it was cause of their fastness (capturing of some short impulses from sensors was essential and AVR offered less measurement error at frequencies that made sense)
btw, I’ve felt into a trap with avr fuses too with my first attiny )
And could you please do a blog on embedded coding standards. What would you say about coding standards like MISRA C or Netrino’s coding standard and others?
I’m on the edge of adopting some standard cause company i’m working for keeps growing and some coding standard became clearly essential. So hearing your opinion would be really interresting.
Also it would be great and usefull to hear about some interresting firmware bugs you’ve found.
A year ago I didn’t even know what a resistor was! and I found the Arduino platform and started to play. Heck I didn’t even know what processor it had! (and i didn’t/don’t care).
As a major newbie in all things EE the Arduino was a great platform to learn. I’ve had successes, failures and the occasional smouldering component! But its been bloody good fun.
As a newbie I had no idea what a PIC was and how it was different from the atmel, this post has really helped to demystify what a PIC is and I’m glad you didn’t go into a deep technical comparison.
Thanks for the great advice.
Leave a reply