PIC vs AVR vs ARM

(a) Significantly better. You can't beat it with an 8-bit processor. (b) At least as good, particularly if you don't mind gnu tools. (c) It'll be harder to really shave the pennies off in a high- volume application, and a bare-minimum ARM board will be bigger, more power hungry and have a higher BOM cost than a bare- minimum AVR or PIC board.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

AVR has wider operating voltage range than ARM, which is useful for dealing with different logic devices.

The only technical downsides to ARM are the minimum system complexity and power, as Tim already mentioned. As always in engineering, it comes down to 'it depends' and the dependency is, in this case, what you need (or want) to achieve with the system.

If you need an ultra low current system monitor, it's hard to beat the AVR or PIC (I prefer the AVR for a number of reasons). So which is 'better' is a much harder question.

Cheers

PeteS

Some more things that come to mind...

Size of package could be an issue as well. Not a lot of ARM options below 48 pins. Almost all ARM have JTAG so if you need OCD you lose multiple pins.

Determinism when toggling I/O ports could be an issue. The ARM has to pass through a number of interfaces before the I/O pin is reached, and this can take some clock cycles and add jitter.

This of course allows an AVR to run at lower clock frequqncy at the same toggle rate.

Putting the I/O on the 32 bit ASB/AHB bus will help but the drawback is higher capacitance on the ASB/AHB bus which should increase power consumption.

ARM parts typically lack byte addressable EEPROM.

It is easy to prototype using DIL packages. Normally not available for ARM.

The AVR has more (but narrower) registers allowing global variables to be stored there.

Bit instructions.

Generally AVR code is smaller than ARM code.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

That is the positive side of ARM. Jtag is always there, and reliable. AVR Jtag, on the other hand, could be disabled, and thus un-reliable by definition.

Last I looked, some years ago, ARM JTAG is also documented -- including the debug interface.

Jon

AVR and PIC aren't really comparable with ARM, the first two are very low cost/power 8 bit machines, the ARM is a higher power, higher cost

32 bit machine. If you need to make a device that needs to run on a coin cell for 2 years, you can't pick an ARM processor, if you need a CPU that can do real time FFT, a PIC won't do it.

I thought so too, but the products from luminary micro (luminarymicro.com), discussed in this newsgroup recently and in Circuit Cellar, have changed my mind.

They make ARM CPUs with very little RAM and flash, on the cheap.... they say less than one dollar in 10k quantities (from an advertising spiel)

ttyl,

--buddy

yes but they are very high power, I think 10x the power of the AVR at

1Mhz, if I remember correctly

To add to this question, I've been doing mostly AVR work and I'd like to branch into ARM. I had planned on just picking up some of Atmel's ARM gear, but would anyone suggest any other first leap friendly ARM procs? The Luminary has already been mentioned and seems interesting.

Jason The place where you made your stand never mattered, only that you were there... and still on your feet

Miem wrote:

JTAG can be disabled in AT91SAM7 circuits as well. It is *MANDATORY* if you want any type of code protection... (The Boundary Scan will still work of course)

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

LMI make Cortex chips which are incompatible with most of the others. Apparently they are financed by ARM themselves. I guess that is one reason why the uptake is not dramatic.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Unless the project requires it, I would say stick with an AVR (my first choice).

I've finished one project using some AVRs and now I'm attempting to use an NXP/Philips LPC2103. I went with the LPC2103 mainly because it has a fast A/D and it's inexpensive. I've worked with 32-bit processors on other projects, including ARMs.

Here's my lengthy comparason of AVR vs. ARM development...

For the AVR I use CodeVision and I find it to be a very good compiler, from a user perspective. I found the peripheral wizard in CAVR is

*very* handy -- you can start using the peripheral very quickly and you don't have to remember the sometimes complicated initalization sequence or register settings. With CAVR, when you're done compiling, you get useful information on RAM and Flash resource utilization. I use UltraEdit32 for the code writing, so I didn't use CAVR's IDE that much, but I found it a sufficient IDE.

I did debugging using the Atmel JTAG ICE mkII and AVR studio and debugWire. I didn't think it would very well, but surprisingly I have very few complaints. The debugging capabilities of the new AVRs (JTAG or debugWire) is quite good, single-stepping was very fast (you hit a key, it steps instantly), and overall AVR Studio worked well. You can do all the standard things you want, look at registers, memory locations, watch variables, etc. Since AVR Studio is written by Atmel, you get views of peripheral registers which are named, with their port bits broken down, and you can toggle the bits as you see fit. There are some rough spots (enabling/disabling debugWire should be done automatically if you goto into programming mode or debug mode, is my major gripe). CAVR has some nice extentions like PORTC.3 = 1 means bit

3 of port C is set to 1. Those kinds of extentions, I found, are very handy in embedded prorgamming.

Contrast this to my current setup with the LPC2103. I am using the GNUARM toolchain set (thanks Rick/Pablo/everyone else who put it together) which in itself works. I followed a tutorial written by "Jim Lynch" which shows how to get GNUARM, the Eclipse IDE and the OpenOCD GBD daemon all working together. I have an existing piece of JTAG hardware that works with OpenOCD, so I didn't have any additional hardware costs.

With the ARM development you'll have to make a choice between sticking your code in FlashROM and executing from there (can be slower, but usually more code space) or putting it in RAM (not much room). This is a limitation of working with a CPU vs. a microcontroller. A big deal for ARM7-TDMI devices is they only have two hardware break-points. So if you want to single-step your code which is in Flash, that requires both hardware breakpoints. If you're using any open source tools, you can almost forget about single-stepping and setting meaningful breakpoints. If you want software breakpoints, you'll need to stick your code in the limited RAM. This a big tradeoff, for the LPC2103 there is 32 KBytes of Flash but only 8KBytes of RAM.

Getting the GNUARM+Eclipse+OpenOCD working is a time consuming setup in my opinion. The compiler works, but you'll spend a decent amount of time mucking with C run-time files (crt0.s), assembly initalization code, linker scripts and other things. Thank fully the LPC2000 forum at Yahoo has some pre-exiting examples you can use as a starting point.

Eclipse has (in my opinion) an overly complicated user interface that can be quite slow and unresponsive at times. It seems like it's very customizable, but if you start digging, you'll find you can't streamline it too much. Using the Eclipse IDE for writing code works OK, but using the "Zylin Embedded CDT Debugger" is not a pleasant experience (at least with OpenOCD), I found it very unreliable. I have since switched to the Insight debugger with my code executing from RAM.

Insight works OK, but single-stepping takes 4-5 seconds per step! The AVR setup single-steps instantly (or so it feels). Insight of course has no knowledge of the chip's peripherals, so if you want twiddle enable bits or look at peripheral settings, you'll have to dump the memory location and work backwards.

So, on paper using one of these ultra-cheap ARM "microcontrollers" looks good, but I think you'll find there's a decent sized leap to get it going. I had been thinking of using these ARM parts in some personal projects, but for now I'm sticking with the AVRs.

Someone might be quick to point out a commercial compiler would work better and that it is unfair to compare CAVR, a commercial compiler, to the free GNU toolset. This might be true, but commercial ARM compilers are usually more than a few hundred $$ and they usually only work with their JTAG debug tools, so you're very quickly locked in. Many of the commercial ARM toolchains (Keil, Rowley for example) are based on the GNU toolchain, so all of those limitations come along for the ride.

My $0.02

John.

Hi Ulf,

You might have been seriously misinformed :-) LMI is not financed by ARM. We are two different companies, and LMI is a ARM partner.

The definition of incompatible is a bit unclear. Same as any Cortex-M3 chips, the LuminaryMicro Cortex-M3 chips are not binary compatible with traditional ARM processors. The Thumb instructions is the same (except BLX and SETEND instructions). But startup code, interrupt handlers and system control codes (e.g. mode switching) will have to be rewritten.

However, application codes developed for LuminaryMicro parts will work on any other Cortex-M3 parts (of course some code might need to be changed if the peripherals / memory map are different).

regards, Joseph

I guess I should add my $0.02 as well. I did not find the transition from PIC/8051 MCUs I was working with before to ARM chips to be very difficult at all. Yes I had to write my initialization code and the linker scripts but they are quite easy to learn. At first I was scared by linker scrips because everytime I opened one up I'd be like "what the hell is this?" but after learning the syntax its not so bad.

I am working with the AT91SAM7S256, which is a pretty pleasant chip to work with.

I did also read the tutorial but I didn't read through all of it. Eclipse is damn terrible, consumes a large amount of memory (seriously, on my system it consumes almost as much physical memory as that FEAR game) and is very slow.

Since I am working on a VERY limited budget, I use Crimson Editor to edit and compile my code and then use Insight to debug it. For me, its simple, simply press Ctrl+2 to do a make clean and Ctrl+1 to build the source to both an ELF and binary. I'd say to learn it because there might be a time in which you will need a 32-bit MCU and you don't want the additional burden of learning at that time.

Also if you are now working with the 8-bit AVR, why not try the MSP430 as well? I have a cheap board on it that is powered with a watch battery and it keeps going (of course the CPU is running off the internal DCO, which is only around 800kHz).

-Isaac

I think you are mistaken. If you compare the ARM MCUs at the same frequency that the AVR runs, you will see that the power for the ARM can be lower than for the AVR. That is one of the big reasons that we recently used an ARM in a new design in place of the AVR which we have typically used in the past.

It may be that in the smaller configurations an AVR can run at much lower power, but if you are comparing apples and not oranges, I think the ARM chips can keep up with most 8 bit parts in terms of power.

We have used AVR MCUs in many of our products and were very happy with them. On a new project I decided to take a look at the ARM MCUs to see if we could branch out from some of the limitations of the AVR. We did a very exhaustive comparison between the various ARM processors and the ATmega128 and found that the ARM chips were generally lower power, lower cost and fit in a smaller footprint on the board. We also were able to use a much smaller crystal.

The ARM we chose for this project was the AT91SAM7S64 due to its combination of low cost and low power. The Philips parts seem to run a close second and may even beat the Atmel SAM7 parts depending on exactly the combination of features you need. If you don't need the lowest power then the other brands of ARM chips could be considered, ST Micro STR7, TI TMS470 and Analog Devices ADuc7 among others.

Did you check out the feature comparison chart at

Click to the Resources page and scroll down to the ARM chips section where you will find three different links for the comparison chart.

Jas> To add to this question, I've been doing mostly AVR work and I'd like to

Depends alot on how fast you run them, but the ARM's always use more power per frequency, the AVR is an 8 bit device that can operate down to 1.8 Volts the ARM is a 32 bit device that requires 3.3 Volts, so it obvious who is going to use less power (assuming all else being equal, process, I/O, RAM, FLASH etc). looking up a couple datasheets

Analog Devices ARM 7021 7.2mA@1.3 Mhz(typical) Atmel Atmega164 .4mA@1.0 Mhz(typical)

At higher speeds the ARM's don't have as bad mA/ Mhz ratio Luminary Micro LM3S101 35mA@20 Mhz (typical, running out of SRAM, no active peripherals) Analog Devices ARM 7021 33mA@41 Mhz(typical)

That is one of the big reasons that we

Which ARM and AVR did you compare? At what speed?

you can make the argument for math intensive applications the ARM can execute it much faster, thus only needs to be on for a much smaller period so less total power that way, was that how you did the analysis?

The AVR's also have much better power down and sleep mode currents, which may or may not be important for your application.

Take a look at:

For $99.00 a 32 bit dev kit. Faster and more capable than most of the small ARMs.

Paul