# Why is AVR used in Arduino?

Why is Arduino using AVR? I understand that they are the official processor but there isn't a reason the code couldn't be ported to an ARM or a Freescale architecture other than cost, right? As long as there is onboard memory, I figured there could be easy migration into those parts.

I see a lot of ARM in industry (seems like every vendor is pushing one into their designs) and was wondering why there wasn't more uptake in the Arduino developer world.

• Who is your market? If you're trying to sell something big in industry, then you'll want an ARM, because if Atmel goes under, you've got nothing left if you're using the AVR. With ARM, there's lots of other vendors that offer near drop-in replacements. The increased complexity of the ARM is less of an issue with good engineers than with hobbyists who don't know basics. If you're selling to hobbyists, the learning curve will be too steep, processor power won't get used, and SMT will be an imagined brick wall. Who are you worried about-hobbyist customers or potential employers? Pls. clarify. Jul 20 '10 at 2:30
• I am not trying to be offensive, but the question begs to be asked. Atmel is more than 25 years old, having very successful market other than ARM, AVR in itself is a very very successful platform. What are the chances of such a company going down. This sounds like saying, "Don't use windows, what if MicroSoft goes down?" Jul 20 '10 at 14:17
• I do agree with your other two points, namely that if you have a hobbyist market, the chances are rare that the full power of ARM will be utilized and SMT being a brick wall. Jul 20 '10 at 14:18
• Isn't there an Arduino Due with a SAM3XE (ARM 32 bits) uC on it? Because, I have one in my hand right now... Feb 13 '14 at 2:12
• I would like to note that "nowadays" there actually are ARM based boards that can be programmed using Arduino (libraries and IDE). Teensy 3.2 is an excellent example of this. sparkfun.com/products/13736
– Paul
Apr 11 '16 at 8:56

Does anyone even care about what you're developing on?

Yes and no. I've been developing on the AVR32 for a particular project, and the development environment (in particular the compile/program/debug cycle) is horrendous compared to, for instance, PIC32.

The customers don't care, except for cost and maintenance, and in the case of an arduino-like system the programmers wouldn't care because the arduino environment and development cycle is leaps and bounds better than the current AVR32 setup.

I just wonder because there is such a strong contingent for AVRs in the Arduino family. I understand that they are the official processor but there isn't a reason the code couldn't be ported to an ARM or a Freescale architecture other than cost, right? As long as there is onboard memory, I figured there could be easy migration into those parts.

There's no reason another processor couldn't be used, but there's a very good reason they've chosen a low end 8 bit device rather than an ARM, MIPS, PowerPC, etc device: Ease of use.

If you've looked at the setup for the even the low end arms, it's an order of magnitude more complex (memory mapping, caching, etc) than an 8 bit processor. But even more importantly - at the time there were no DIP arm processors, and these were meant to be used and buildable by artists and hackers, not necessarily electronic technicians and engineers who feel comfortable with even a 48 pin TQFP.

The reason the AVR was chosen over the PIC is that the PIC doesn't really have a widely used, open source, free C compiler, among other things (the SDCC port isn't mature).

I see a lot of ARM in industry (seems like every vendor is pushing one into their designs) and was wondering why there wasn't more uptake in the Arduino developer world. Thoughts?

Mainly it's due to ease of use - complexity, easy to solder, cost, and the fact that there's not much need for it. Developers like the idea of having a lot of power, but at the end of the day when all you need to do is move some servos and flash some lights with a low-end FFT, an 8 bit processor is just fine.

Even the low end cortex ARMS coming out in 28 pin packages are still SOIC, not DIP.

So the AVR had all the right features:

• Easy to solder
• Easy to get via mail order all over the world
• Free GCC C compiler
• Easy to understand the processor and peripheral setup and usage
• Cheap
• Ubiquitous - lots of people and experience surrounding the AVR family

Largely this is still true - I don't know of an ARM in a dip format, and the adapters make it significantly more expensive than the AVR. For the most part, manufacturers don't think that a DIP packaged 32 bit processor is going to be very profitable.

• There is one, the Parallax Propeller. It has eight 32-bit CPUs on the chip, and comes in DIL, QFP and QFN packages. Jul 20 '10 at 1:53
• This is spot-on. AVR over PIC due to licensing, and AVR over ARM due to simplicity of software and toolchain and soldering ability. For your own projects, this may not apply. However, if you want to develop an ARM-duino, take a look at the other, similar projects. They don't catch on like the AVR has. This may also be due to the Arduino dev environment. Jul 20 '10 at 2:19
• Which AVR32 tools are you using - I use IAR on both AVR32 and MSP and have found this environment highly capable. The cost is not an issue in a professional environment - equivalent to less than the cost of employing an engineer for a week.
– uɐɪ
Jul 20 '10 at 8:10
• This claim about tools can be overcome - Arduino uses gcc which also has an AVR32 port available. Jan 23 '13 at 20:19
• NXP now has a few Cortex-M0 ARMs in a DIP package. I think from the LPC11xx family. I imagine their target market is extremely cheap, low quality, single sided PCB, in appliances. Apr 28 '13 at 20:30

Since you seem to be polling for opinion, here's my $.02. Whether I'm working on an ARM or AVR does matter (and hence, I do care), mostly based on what it is I'm trying to do. There are use cases where an AVR makes sense, and there are those when an ARM does. In general, there's also a tradeoff one makes between, say, AVR and PIC. First off, while I'll probably get in trouble for saying this, the "strong contingent in the Arduino family" is something of a vocal minority. Most arduino folk (users) I've come across are the kind who would rather treat their hardware in the same way they'd whip up a python script to do something amusing, often with a lower level of understanding of the intricacies involved than they would have when they'd do "from numpy import foo" . While there is some merit in the Arduino way of doing things, there's also a whole lot of scope for criticism. I think it's worthwhile to look at the AVRs, aside from the Arduino ecosystem. The Arduino contingent has also benefited greatly from the reasons which made the AVR something of a defacto standard for hobbyist things - a mantle it's been taking over increasingly from PIC even before arduino made its appearance. The AVR's direct competitors would be the PIC and to a degree the MSP430, which is gaining traction owing largely to TI's heavy marketing push combined with its subsidizing tools. ## Ecosystem As has been mentioned in other answers, the AVR is the one family which has a clean, standardized way to get from zero to hello world using free tools. The avr-gcc port, the pieces that make the winavr toolchain, plenty of programmer schematics with varying complexity and features but still bound by the authority derived from being supported by avrdude make it much easier than dealing with getting the toolchain worked out. The PIC's ecosystem is a nightmare, with any number of compilers, programming tools, assemblers, what have you. Many of them aren't compatible with each other. Most of them are paid. Not all of them are good. More importantly, there isn't a defacto standard. The free / open source alternatives (say, SDCC) leave much to be desired, but more than that, have failed to acquire a status of defacto standard like avr-gcc and company have. Even with the software toolchain worked out, you would at the very least have to invest in a programmer of some sort. The PICkit may just cost 20$ or so, but when you have to figure out how to buy it online (Credit Cards, international shipping, forex hassles), it can be a deal breaker for hobbyists. There isn't a good, reliable programming circuit with the standardization necessary to give a newbie the courage to invest effort and resources in getting from the point of finding a source for the IC to the point where Hello World is programmed and the LED is blinking.

MSP430 is marginally better, mostly because its newer (atleast in terms of popularity) - There's much less noise to contend with. TI ships IC samples to you with efficiency I haven't seen anywhere else. mspgcc is in OK shape, and there's even an open source debugging software that isn't hard to find or setup. The problem, though, is that it isn't as hobbyist friendly as the AVR is. You still have the problem of the Programmer, which is more expensive than what you'd need to buy for a PIC. The 3.3v supply operation puts up a percieved barrier to people who are used to 5v Logic. And it doesn't scale in DIP - There are low end ones available, but not once you reach the more fleshed out chips.

## Ease of Use

DIP vs SMD, I think, is a more important distinction than it is often credited to be. A DIP IC can be used on breadboard, general purpose boards, whatever they're called where you live, and so on. An SMD IC necessarily requires a fabrication run, or purchase of adapter boards which aren’t always easy to come by in the size or shape you want.

Datasheet quality, application notes, and the readability of them, also, makes a difference. Atmel seems to do a marginally better job at that. Of course, that is a highly subjective assessment.

AVRs can use an internal RC while PICs often don't. They require a crystal, which makes it slightly dicey when combined with a paucity of confidence.

AVRs also seemed more friendly with in-system programming compared to PICs a few years ago, although I could very easily be wrong there.

# AVR vs ARM

Your question, though, had to do with AVR vs ARM. Like I said at the beginning, AVR and ARM occupy different spaces in the spectrum. If you've something that you can do with an AVR, then why would you want to do it with an ARM? ARM's are more expensive, require higher part counts, consume more energy, make for more complicated code, need more expensive fabrication processes. Soldering a 100 pin TQFP is more expensive than soldering a 40 pin DIP/SOIC, depending on how you measure cost. This may not hold if you're producing in large volumes and using production techniques friendly with that, but if you are doing that, then the price differential will be become even more compelling to go with the cheaper solution.

As a go-to controller for general hacking around the house or what have you, I'd say AVR's easier to use because:

• More standardized from a hobbyist perspective, more code I can reuse from the internet because there aren't so many compiler variations, and variations between register names and API among family members. (Try porting LPC ARM code to ATMEL ARM hardware, you'll see what I mean)
• Code becomes inherently more complicated (It does. Really).
• The toolchain takes additional work to setup.
• Makes interfacing slightly easier. ARMs would generally drop you down to 3v3 or 1v8 Logic making interfacing to other toys slightly problematic.
• Cheaper
• Getting an ARM chip at the local hardware store isn't an option for me where I live, getting an AVR is.
• I don't recall any PICs, aside from some OTP parts where the fuse bits were pre-programmed as part of factory testing (the only way to confirm that LP, XT, or HS mode worked was to configure the chip for that mode) that required a crystal. Some did require an external resistor and cap to use RC mode, and had pretty rough specs on the frequency it would produce, but I don't recall any PICs without a design option for internal or external RC. Have I forgotten any? Jan 23 '13 at 17:06
• In actuality, the ARM/AVR cost is pretty close to a wash for comparable resources. And the packages that would get used in a production setting aren't necessarily that different, since it would likely be the QFP or QFN variants of either. Support circuitry required is pretty comparable, too. Jan 23 '13 at 20:24
• @Chris : When you factor in the resources each chip provides, I'd say ARM will come out cheaper almost every time. That said, the point is that in situations where AVR makes sense in a production environment is where you don't need the horsepower and/or the bells and whistles that an ARM brings to the table. When weighted with utilized resources instead of available resources, the AVR comes out cheaper. I don't think the support circuitry is comparable (1 tantalum capacitor as against 4, and other similar spiralling). ARM isn't an expensive beast as much as it can be overkill. Jan 24 '13 at 10:26
• @supercat : Maybe. I'd have to check. It never seemed obvious to me the few times I looked at it. I do know that atleast some dsPICs can fall back to internal, though, if you set them up right, but even that took a little guesswork and fooling around to discover. Microchip datasheets leave much to be desired, IMO, but then again, depends on what market you're looking at. Jan 24 '13 at 10:30
• @ChintalagiriShashank - ignoring the other peripherals and just looking at flash & ram sizes there are ARM offerings which are fairly competitive with for example the ATMEGA328p. And don't get too distracted by bypass caps. For one, tantalum can make sense as a supply filter, but actual bypass caps are lower value local reservoirs for the high frequency switching requirements and so can be cheap SMT ceramics. Also, what drives the need is clock and I/O switching frequency - at a comparable clock rate, the ARM will not actually need all the recommended bypass caps. Jan 24 '13 at 14:07

Arm development is coming along - take a look at the following projects.

Maple Leaf

XDuino

Cortino

Illuminato

ARM PRO family

And now an ARM in a DIP package.

NXP LPC1114FN28

BASICchip

Part of the reason for the large community interest in the Arduino is the physical standardization. As screwy as the physical layout is, by including a standardized expansion option, the Arduino developers allowed people to come up with their own solutions. If you want to replace the base Arduino board with another board that uses a different microcontroller, you can. IIRC, someone has already built a PIC-based board that uses the Arduino form-factor. (The PIC Ardunio board doesn't have the same form factor, but is otherwise similar.)

Another reason for the success of the Arduino is in its openness -- most of the PIC-based microcontrollers were closed; They used proprietary hardware implementations, so if you wanted to redesign the board to better fit into a specific space, you were out of luck. They used custom firmware and proprietary development tools, so that if you had bugs or wanted to expand the capabilities, you were out of luck. With the Arduino, every single piece of the puzzle is open: you can buy parts anywhere, rearrange them as you need, improve or modify the firmware AND the development tools. You can start simple with the Arduino IDE, but you can still shift to C or Assembly anytime you need it.

Personally, I like the Arduino because it gets a lot of things 'just right': It's not too expensive, it's not locked into proprietary tools, it's easy to start with, it's got a lot of capability, and it has a large user community, which continues to expand and do neat things.

• You listed very good reasons that microcontroller hobbyists like Arduino, but the question was about ARM vs AVR. Arduino was mentioned due to its decision to select the AVR series of MCUs for its implementation. I think some more relevant answers lie below your post; for example, the fact that Atmel supports its AVR series with a C compiler. Good info nonetheless for someone unfamiliar with Arduino, however.
– ozmo
May 14 '11 at 17:17

A major advantage to the ATmel uCs is that there is a free compiler available for Linux, PC and Mac. Add to that a simple cross-platform GUI and you have a free development system that runs on all platforms.

Cost is a major factor for the hobbyist boards. Since you want to have a starter price in the \$30 range you need to have a uC cost that is no more than a couple of dollars.

ARM would be a excellent candidate for the higher end boards. A lot of companies license the ARM core and add peripherals. I believe there are free compilers for Linux, PC and MAC.

I really like the Freescale Coldfire for high end boards. I worked on a board for test equipment that used a 5206e. We added some DRAM and high accuracy A/D and D/A converters. It was a cost-effective solution. I have not recently compared Coldfire to the wide variety of ARM's.

Some of the 8-bit Freescale uCs are nice but I am not sure if they have free tools.

• Thanks for the useful comment, but the 8 lines of 'signature' is a little extreme, these stackoverflow-based sites tend to look down on advertising your own sites in your answers.
– davr
Dec 18 '09 at 16:33

I agree with the dip package, disagree that arms are harder to configure, lpcs are, but they are not the only kid on the arm block (atmel itself for that matter). From what I remember and experienced, Atmel was and perhaps still is just more developer friendly. The AVR butterfly helped them greatly to get more users to their already good sized and happy user base. The PIC was just painful in a lot of ways, the avr tools were there, programming was a breeze and didnt cost you much more than some wires and a connector from radio shack. The tools are there and free but not as easy as mainline gcc where you find the arm and thumb solutions. Long before the arduino came out the AVR was the chip of choice for hobby projects.

Nothing can compete with ARM right now. For ever other processor you touch in a day you touch a few ARMs at a minimum. For some almost everything you touch uses an ARM. It is a natural fit as the 8 bit killer, can get much better performance than an 8 bit for the same size, price, etc. Tools are much better, instruction set is much cleaner than most of its competition so the same code runs that much faster, etc. Because anyone and their brother can embed an ARM and it is not locked into a company like pic, avr, msp430 there are a wide variety of solutions, and as many different ways of dealing with the microcontroller rom/ram mixtures and the interrupt vector table. Sadly the more popular solution is the most painful. Try a sam7 or something like that or a stellaris. There is an armmite pro which is an attempt to make an arm based arduino plugin, or something close to that and I actually like that board.

It isnt always the processor that is the problem, some chips have known can problems, some have other known problems. some may not offer a open collector io pin with a weak pull up and you would have to put hardware outside the chip to interface to something, where another may have that available on one or all of the pins. I recommend sampling the field, trying the different companies and solutions so that when you want low power you can easily use a msp430, you want processing power in a small chip you go with arm or if you want to make an open project that you hope others will build in their garage you base it on an arduino, if you can.

The bottom line though for your question is it really depends on your application and how you write it and the performance and resources you are interested in. In the same way that gcc or firefox will run on many different platforms and processors, you most certainly can write your C application to run on a wide variety of microcontrollers...IF...you have a microcontroller specific abstraction layer, which has a cost. if the microcontrollers have similar enough features and have the features you need and you plan ahead and incorporate those. If the next platform has enough memory/resources. You are more interested in portability than performance, etc. Arguably you need to plan for this ahead of time. or at least on the first switch from A to B you re-design the software, if/when there is a third switch from B to C it is less painful.

• Nothing can compete with ARM right now. <- In industry. In the hobbyist world, AVR is still really, really strong, and will be for a long time. Jul 20 '10 at 2:22
• Absolutely agree one world avr is crazy popular, another world which happens to be the one where the products we buy a touch and use are, where the money is, it is something else. So for fun at home learn one, for your day job learn the other, and and get to play all day and all night. Jul 20 '10 at 3:49

I know you said "other than cost", but really that is the most important thing for hobbyists. You don't need more than one UART or more than one SPI on what is meant to be a cheap, generic platform. Once you start needing >20mhz speeds, you really should be looking at a custom setup (ymmv of course)

A couple of small points not raised in the other comments:

• An Arduino is intended for small scale I/O projects, adding a small amount of intelligence to a circuit. They are typically single threaded, real time devices, where an ARM would be very wasted. There are plenty of options for ARM boards of course, but the use case is normally different - typically they boot into a full scale operating system.

• By targeting this small scale use case, everything else gets easier - pin count, support components, power consumption etc.

That said, for the target use case of the Arduino, it isn't like you are slumming it. A 16MHz processor is a lot of grunt for your Alarm clock with integrated LED chaser (or whatever :)

Arduino is available on other processors. Check out the ChipKit from Microchip, for example. That uses a PIC 32.

• Sorry Olin, the title was an incorrect attempt of mine of editing the question, made from its body. It should be more correct now. Apr 26 '13 at 12:13

Second try (the original post title and question from +3 years ago was changed since original answer):

Chicken and egg, but especially during the last few years (2007 ARM launched Cortex-M architecture), 32-bit MCUs have grown in popularity and vendors have been better at providing faster and easier access for the EE community when designing in >8-bit micros (better sw tools, free tools, more examples...).

As Atmel, along with 100 others, offers Cortex-M devices as well and have upgraded its toolchain to support AVR to ARM, plus the long-standing relation, the Arduino upgrade path is given(?). But, alternatives pop up and seem to involve alternative attempts to gain it's share of the "hobbyyist" cake: e.g. mbed by NXP/ARM, and recently "CoAction Hero", : 32-bit Open-Source ARM Cortex-M3 Board on KickStarter.

Final thought, 3 years after the initial question: when all vendors offer 32-bit Cortex-M cores - could the Arduino now actually become non-Atmel?

Original answer: Alf-Egil Bogen, one of the Atmel AVR co-founders, looks at some of the background for the industry's move from 8-bit to 32-bit ARM cores in his video blog here http://blog.energymicro.com/2013/04/24/avr2arm/.