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.
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:
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.
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.
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.
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.
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:
Arm development is coming along - take a look at the following projects.
And now an ARM in a DIP package.
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.
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.
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)
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.
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.
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/.