PIC vs AVR vs ARM

rickman wrote:
> 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.

What do you mean, "a much smaller crystal"?

Hi Issac,

In article <1159892751.506769.114790@i3g2000cwc.googlegroups.com>, 
x86asm@gmail.com says...

> 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.

You're right, learning all that isn't too horrible, but when you're 
getting up to speed on an entirely new part, that's one less thing you 
want to worry about.

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

Do you execute your code from RAM or Flash?  The '256 has ample of both, 
so I suspect the tradeoffs in going from a uC to a uP weren't as great 
for you.  Do you plan on using a '256 in production / final product, or 
is that your development platform?

> 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.

When you re-compile your code, do you have to quit Insight?  Are you 
using OpenOCD as well?

I find for some reason, arm-elf-gdb opens the main.out (.bin, or 
whatever) in a locked read-only mode, so I can't re-compile until I kill 
Insight (or whatever is the front-end for gdb).  I find that a real 
PITA.  AVR studio was nice and would pop-up a message saying it noticed 
the executable changed and if I wanted to reload the AVR.

> 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).

Well, I tried the MSP430 on a project once and I wasn't blown away by 
it.  I think the MSP430 niche is "low-power" and all the various 
clocking modes it offers.  But from a performance perspective, many 
instructions are not single-cycle, so the AVR typically runs neck and 
neck with it or faster.

I like the idea of working with a 16-bit uC, I think that's the perfect 
compromise. Since a lot of data one uses in the real world (with A/Ds, 
D/As, etc) is more than 8-bits wide it typically fits nicely in 16-bits.  
But, I just didn't find the MSP430 to offer too much more than the AVRs.

I will add, I don't think TI has an equivalent to AVR Studio, which 
means if you want to do debugging, etc that means something like Rowley 
CrossWorks.

John.

steve wrote:
> rickman wrote:
>
> > 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.
>
> 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)

You are comparing one of the more power hungry ARM chips.  Try
comparing the SAM7 parts to the ATmega128 which is the comparison we
did and found the SAM7 to use less power at a given frequency.  You
said it well that the AVR would use less power if everything were
equal, but everything is not equal.  The SAM7 and most of the other ARM
parts are a much newer process with 1.8 volt cores.  You can even power
the cores directly from 1.8 volts while still using the IOs at 3.3
volts to be compatible with other logic.


> 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)

Again, the Luminary parts are in the high power group.  In fact, if you
check the data sheets you will find there are roughly two groups of
ARM7 MCUs when it comes to power.  The SAM7 and LPC2xxx parts are about
100 mW at full speed and the rest are mostly over 200 mW full speed.
How their power scales with frequency varies so you can't generalize
from a single comparison.  There are clearly ARM parts available that
will beat the ATmega128 that we had been using when it comes to power.


>   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.
> >
> Which ARM and AVR did you compare? At what speed?

ATmega128 and SAM7S64 at 4 MHz.

> > 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.
>
> 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?

No, the SAM7 chips scale very well with clock speed.

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

Yes, if you are going for a super low power device that spends a lot of
time not even running, then the 8 bit micros may be a better choice.
But for most applications the ARM chips do just as well if not better.

Mike Silva wrote:
> rickman wrote:
> > 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.
>
> What do you mean, "a much smaller crystal"?

Just that, physically smaller.  The crystal used with the ATmega128 is
8 MHz max which can not be found in the really small packages.  We were
running at under 4 MHz and the crystal was huge at 11 x 7 mm, IIRC.
The part we are using on our new ARM designs is 3.2 x 2.5 mm at 18.432
MHz.  While I was qualifying the crystal I found that they did not have
enough info in the data sheet to select a crystal.  To select a crystal
that you can be sure will work reliably you need to know the required
ESR and shunt capacitance.  Atmel did not spec this at all in the April
'06 data sheet. They have updated the data sheet to show this data now,
but in a very funny way.  They give you the ESR values to use at
specific frequencies without telling you which value to use between
those frequencies.  I tried to get them to correct the table, but they
did not seem to feel this was a problem.  Do you think this is a
cultural thing?

ESR is also important if you are trying to use as small a part as
possible.  The higher ESR you need, the larger the crystal you will
have to use.  So when Atmel left the gaps in the table you have to
guess which value applies.  If you guess one way you will have to use a
larger crystal, if you guess the other way your design may not work
reliably.  Considering that the SAM7 parts come in as small as 7 mm
square packages, I would think the size of the crystal would be
significant in a number of designs.

rickman wrote:

> > Which ARM and AVR did you compare? At what speed?
>
> ATmega128 and SAM7S64 at 4 MHz.
>
Hmm, the PLL on the SAM7 probably takes more current then the entire
ATmega128, but I guess you can disable that and run at 4Mhz directly
from the crystal, do you remember what is your total current was at
4Mhz on the SAM7 device?

steve

John wrote:
> Hi Issac,
>
> In article <1159892751.506769.114790@i3g2000cwc.googlegroups.com>,
> x86asm@gmail.com says...
>
> > 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.
>
> You're right, learning all that isn't too horrible, but when you're
> getting up to speed on an entirely new part, that's one less thing you
> want to worry about.
>
> > I am working with the AT91SAM7S256, which is a pretty pleasant chip to
> > work with.
>
> Do you execute your code from RAM or Flash?  The '256 has ample of both,
> so I suspect the tradeoffs in going from a uC to a uP weren't as great
> for you.  Do you plan on using a '256 in production / final product, or
> is that your development platform?

Yes the chip has ample flash and RAM, I am running out of Flash though
in ARM mode. I do not yet want to mess with the Thumb stuff. I am using
the '256 as a simple dev platform to get a feel for the chip (and ARM
chips in general). The tradeoffs werent too great I guess. I really did
like working with the 8051, it was quite simple to use and its hardware
and architecture were very well documented. But I figured I would learn
about the ARM since many of you are enthusiastic about it. I'm not a
professional, so I am not involved in any professional work. But let's
just say I am an apprentice ;).

> > 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.
>
> When you re-compile your code, do you have to quit Insight?  Are you
> using OpenOCD as well?

Yup, I must or else the linker stage of my make file will complain. I
am using the OCDRemote from Macriagor (sp?) and a "Wiggler" compatible
JTAG cable. It is horrendously slow sometimes. I have to close the
local variable view to speed it up. Sometimes that doesnt even work :(.


> I find for some reason, arm-elf-gdb opens the main.out (.bin, or
> whatever) in a locked read-only mode, so I can't re-compile until I kill
> Insight (or whatever is the front-end for gdb).  I find that a real
> PITA.  AVR studio was nice and would pop-up a message saying it noticed
> the executable changed and if I wanted to reload the AVR.

I'll admit I havent played with AVR. But it seems like the people doing
their design projects at my school are in love with it (and the PIC,
not surprisingly though since one of our alumni grads works at
Microchip...). They also love the Freescale 56000 series DSPs, they
seem to have simulators for that DSP on the computers.

I did do a brief foray with the AVR Studio some time ago and really
liked the IDE. The simulator was very powerful too. I guess that's why
my peers like it so much.
> > 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).
>
> Well, I tried the MSP430 on a project once and I wasn't blown away by
> it.  I think the MSP430 niche is "low-power" and all the various
> clocking modes it offers.  But from a performance perspective, many
> instructions are not single-cycle, so the AVR typically runs neck and
> neck with it or faster.
Yes it is a more "heavy" RISC chip. Its instruction set somewhat leans
more towards traditional CISC processors. But a plus side I found with
the MSP430 is that the MSPGCC is very simple to use. No startup
initialization is necessary (compiler has startup object files for each
variation of the 430) and all you need to do is plus a special
attribute flag on a function and it will be declared as an ISR and the
vector table will automatically be patched for you. No mess, no
worries.

> I like the idea of working with a 16-bit uC, I think that's the perfect
> compromise. Since a lot of data one uses in the real world (with A/Ds,
> D/As, etc) is more than 8-bits wide it typically fits nicely in 16-bits.
> But, I just didn't find the MSP430 to offer too much more than the AVRs.
>
> I will add, I don't think TI has an equivalent to AVR Studio, which
> means if you want to do debugging, etc that means something like Rowley
> CrossWorks.
My first 8-bit MCU was the PIC, so the MSP430 is a refreshing change. I
found the PIC's to be pretty good for power consumption. The MSP430 has
a better architecture and a free GNU compiler that I can readily use,
it was a no brainer to switch over and use it in my low power projects.


> John.

-Isaac

"rickman" <gnuarm@gmail.com> skrev i meddelandet
news:1159903397.463883.11040@k70g2000cwa.googlegroups.com...
> 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.

When power is an issue, you typically have to spend as much
time as possible in sleep mode, and the Picopower AVR
will be at least an order of magnitude better than the AT91SAM7 here.

Also, when running from an R/C oscillator you can turn on/off almost
instantly,
while the AT91SAM7 probably have to start the PLL which will take ~16 ms.
One drawback of Picopower is that the startup time from sleep
is increased from a few clock cycles to about 70 us.
This is the time it takes to activate the brownout detector which is
disabled in deep sleep.
(Don't worry, the part is protected from Brown-Out by the Power On Reset in
deep sleep)

I think the PicoPower AVR is therefore hard to beat when you really need low
power.

> 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 www.gnuarm.com?
> Click to the Resources page and scroll down to the ARM chips section
> where you will find three different links for the comparison chart.
>
>
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

>
> 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.

Hear, Hear  :-)

> 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.

I attended an Eclipse Seminar, and 1GB RAM is minimum
and many need 2 GB to run properly.

> 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).
>

Or try the new AVR PicoPower chips.
Draws even less current...


> -Isaac



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

> Just that, physically smaller.  The crystal used with the ATmega128 is
> 8 MHz max which can not be found in the really small packages.  We were
> running at under 4 MHz and the crystal was huge at 11 x 7 mm, IIRC.
> The part we are using on our new ARM designs is 3.2 x 2.5 mm at 18.432
> MHz.  While I was qualifying the crystal I found that they did not have
> enough info in the data sheet to select a crystal.  To select a crystal
> that you can be sure will work reliably you need to know the required
> ESR and shunt capacitance.  Atmel did not spec this at all in the April
> '06 data sheet. They have updated the data sheet to show this data now,
> but in a very funny way.  They give you the ESR values to use at
> specific frequencies without telling you which value to use between
> those frequencies.  I tried to get them to correct the table, but they
> did not seem to feel this was a problem.  Do you think this is a
> cultural thing?
>

> reliably.  Considering that the SAM7 parts come in as small as 7 mm
> square packages, I would think the size of the crystal would be
> significant in a number of designs.
>

Internal R/C is of course 0 mm^2
With a good calibration source you can live with the imprecision.
Without a good calibrate you can sometimes scan the frequency range
and lock when you have the right frequency.
Some low cost mobile phone accessories use this method when they
communicate over the UART with the phone.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

>> Do you execute your code from RAM or Flash?  The '256 has ample of both,
>> so I suspect the tradeoffs in going from a uC to a uP weren't as great
>> for you.  Do you plan on using a '256 in production / final product, or
>> is that your development platform?
>
> Yes the chip has ample flash and RAM, I am running out of Flash though
> in ARM mode. I do not yet want to mess with the Thumb stuff. I am using
> the '256 as a simple dev platform to get a feel for the chip (and ARM
> chips in general).

You will get a performance boost by running in Thumb mode on the SAM7.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB